Messages in this thread | | | Date | Tue, 02 Nov 2004 19:01:55 +0100 | From | Pierre Ossman <> | Subject | Re: __GFP flags and kmalloc failures |
| |
Marcelo Tosatti wrote:
>On Tue, Nov 02, 2004 at 04:49:20PM +0100, Pierre Ossman wrote: > > >> >>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? > > I'm currently running 2.6.9. No external patches (except for my own stuff related to this driver).
>-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. > > > No I haven't. Only saw it today and I usually don't use the -mm tree. I've gotten the impression it's a bit too bleeding edge for me ;) What do these patches add to the mix? I'm also not familiar what the order means. I guess it's some kind of priority system? Is there a way I can raise my priority to get access to the memory that kswapd actually keeps available?
>>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. > > Is there any other way of increasing the chances of actually getting the pages I need? Since it is DMA it needs to be one big block.
Rgds Pierre - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |