Re: linux-kernel-digest V1 #98
Tue, 27 Jun 1995 11:59:26 +0100 (BST)

> > Even then, I was told that kmalloc takes care of that when called with
> > proper parameters (GFP_DMA) the alignment is no problem too. When you alloc
> > more than fits on one page you'll get complete pages anyway. Even if not or
> > if 4096 alignment doesn't suffice you can just kmalloc some more memory
> > and place your dma buffer properly aligned into the bigger kmalloced area.

This one comes up every couple of months.

If you __get_free_pages (note the 's') for 2^n pages the current MM guarantees
they are aligned to 2^n page boundaries (at least), i.e. if you ask for any
number of pages <64k, they won't cross a 64k boundary. This was one of the
inherent advantages of the current system (that's unless someone has changed

> A while ago I changed a driver I was working on to kmalloc(....,
> GFP_DMA). Unfortunately, I found this worked unreliably (I have not
> checked this recently). Frequently, the kmalloc()'s failed though
> there was plenty of VM available. get_dma_pages() (which is called by
> kmalloc for DMA pages) just keeps calling get_free_page() until it
> gets a page below 16MB - there is no technique for indicating a
> preference for such pages. get-dma-pages() eventually gives up and
> returns to kmalloc() without getting a suitable DMA page. This problem
> is most noticeable when using loading modules which use DMA after
> memory consumption has been pushed past the 16MB mark. There is also
> no control over alignment of the DMA pages.

(as you don't need it).

get_dma_pages might be considered a bit of a bodge in this respect.

> Previously, I had been using David Niemi's DMA manager patches, which
> reserved a separate pool of DMA pages at boot time, and supported any
> alignment requirements you could think of. However, David has
> indicated that this is not a favoured approach. Is there any plan to
> provide some form of DMA support which selectively targets the memory
> below 16MB, and supports alignment requirements? There are a number of
> people working on device drivers for laboratory data acquisition who
> would find this useful.
> Thanks for any info or insights anyone can offer in this regard.

Here's another 2 possibilities (1st was Linus' solution).

1 Maintain a separate set of free queues for pages in the 1st 16Mb and the
rest, and add preferentially remove from the second set unless a GFP_DMA
is set, under which circumstance it should remove from the 1st. This means
mucking about with RMQUEUE etc. a bit either to take freearealist as
a parameter or to determine which one to use there and then.

OR 2 write a version of __get_free_pages which traversed the free area list
to find a suitable page. This is tricky as it can be slow and the
whole point of __get_free_pages was that it was fast and reentrant.

Thus (1) is probably the better solution.


Alex Bligh : ,-----. :
Computer Concepts Ltd. : : :
Gaddesden Place : : ,-----. :
Hemel Hempstead : `-+---` ` : Tel. +44 1442-351000
Herts. UK HP2 6EX : | , : Fax. +44 1442-351010
: `-----` :