Re: Bugs and wishes in memory management area

Rob Riggs (
Thu, 21 Nov 1996 02:12:28 -0700 (MST)

On 20-Nov-96 wrote:
>> DMA memory". That makes modules unreliable. Of course I don't see
>> why modules are apparently using GFP_ATOMIC | GFP_DMA. When loading a
>> module I think we can swap.
>GFP_DMA implies GFP_ATOMIC (rightly or wrongly)

>From my reading of the source and headers it seems that GFP_DMA implies

>From mm.h:

> #define GFP_BUFFER 0x00
> #define GFP_ATOMIC 0x01
> #define GFP_USER 0x02
> #define GFP_KERNEL 0x03
> #define GFP_NOBUFFER 0x04
> #define GFP_NFS 0x05
> /* Flag - indicates that the buffer will be suitable for DMA.
> Ignored on some platforms, used as appropriate on others */
> #define GFP_DMA 0x80
> #define GFP_LEVEL_MASK 0xf

>From kmalloc.c:

> if (priority & GFP_DMA) {
> dma = 1;
> type = MF_DMA;
> pg = &bucket->dmafree;
> }
> priority &= GFP_LEVEL_MASK;

This would seem to imply that one can do:

ptr = kmalloc(size, GFP_DMA | GFP_KERNEL);

The comments in mm.h clearly state that "GFP_DMA" is a flag, not an
actual priority level. However GFP_DMA & GFP_LEVEL_MASK = GFP_BUFFER.
And GFP_BUFFER does not try very hard to free pages.

I think the original poster is correct in that we could try harder
to free pages if DMAable RAM is not immediately availible, even
by paging if necessary. Can modules sleep during initialization?
If we can't, then the affected modules may need to defer allocation
of the DMA buffers until it can sleep.