Re: __GFP flags and kmalloc failures

[Marcelo Tosatti]

On Tue, Nov 02, 2004 at 04:49:20PM +0100, Pierre Ossman wrote:
> I'm trying to allocate a buffer to be used for ISA DMA and I'm 
> experiencing some difficulties.
> 
> I'm allocating a 64kB buffer (max size for low ISA DMA) using:
> 
> kmalloc(65536, GFP_KERNEL | GFP_DMA);
> 
> The choice of flags are from another driver that does ISA DMA so I 
> didn't put too much thought into them at first.
> 
> The problem is now that this allocation doesn't always succeed. When it 
> fails I get:
> 
> insmod: page allocation failure. order:4, mode:0x11

This is a big allocation and the kernel is having problem finding such a 
big page, due to memory fragmentation (as you mention below).

What kernel version are you using?

-mm contains a series of patches from Nick which should make the situation 
better, have you tried it? Currently kswapd doenst honour high order 
page shortage.

> and a nice little stack dump.
> 
> Digging around in gfp.h to see if I have the proper flags I find that I 
> currently have the following:
> 
> * __GFP_WAIT : This seems to indicate that the process should be put to 
> sleep until the allocation can succeed. Doesn't seem to work that way 
> though.
> 
> * __GFP_IO : What is meant with physical IO? PCI DMA? This buffer needs 
> only be read by the ISA DMA controller and the driver in kernel space. 
> Any useful data is copied to other buffers.
> 
> * __GFP_FS : Since the data is copied before use this probably isn't needed.
> 
> * __GFP_DMA : From what I've been told, this flags causes the allocator 
> to do the magic required for the buffer to end up i memory accessible 
> from the ISA DMA controller. So this seems to be the only flag that 
> actually does anything useful.
> 
> My question is now, why does the allocation fail (sometimes) and what 
> should I do about it?
> 
> Memory fragmentation and overusage seems like reasons to why but why 
> doesn't the kernel throw out cache pages and reorganise user pages so 
> that the allocation can succeed?

We're working on that.

> As for solutions I've tried using __GFP_REPEAT which seems to do the 
> trick. But the double underscore indicates (at least to me) that these 
> are internal defines that shouldn't be used except for very special 
> cases. What is the policy about these?

Its OK to use these flags externally. They might change in future major kernel
versions though, or even future v2.6 release.  ie its not a stable API.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/