> Date: Mon, 26 Jun 1995 13:24:41 +0200 (MSZ)
> From: Michael Weller <eowmob@exp-math.uni-essen.de>
> 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.
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.
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.
cheers,
glenn.
--Glenn Moloney glenn@physics.unimelb.edu.au School of Physics, Phone: +61 3 9344 5081 University of Melbourne, Fax: +61 3 9347 4783 Parkville, Australia 3052.