Re: Mapping Kernel-space to User-space
Linus Torvalds (Linus.Torvalds@cs.helsinki.fi)
Tue, 27 Jun 1995 09:12:06 +0300
glenn@physics.unimelb.EDU.AU: "Re: Mapping Kernel-space to User-space" (Jun 27, 7:28):
>
> 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.
__get_dma_pages() should be more or less fixed in 1.3.4, so DMA
allocation should be safe. However, you are right that there are no
guarantees that any free memory exists in the <16MB range, so especially
with multi-page allocations __get_dma_pages is likely to fail
(single-page allocations should be ok).
As to alignment, that is also guaranteed: __get_dma_pages will never
return unaligned areas, for the simple reason that the low-lovel memory
management uses a powers-of-2 buddy system which naturally aligns
everything.
In short, I think that as of 1.3.4, dynamic DMA allocation really should
be taken seriously. I'd like to see stuff like the sound driver done as
a module, for example.
Linus