Messages in this thread | | | Date | Tue, 2 Nov 2004 13:26:29 -0200 | From | Marcelo Tosatti <> | Subject | Re: __GFP flags and kmalloc failures |
| |
On Tue, Nov 02, 2004 at 07:01:55PM +0100, Pierre Ossman wrote: > 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?
They make kswapd free pages when high order allocations fail.
> 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?
order indicates the order which 2 will be elevated, to indicate how many physical pages this "high order page" is, in size.
"2 ^ 0" = 1 page, order 0 , "2 ^ 1" = 2 pages, order 1, "2 ^ 2" = 4 pages, order 2 and so on. > > >>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.
__GFP_NOFAIL, from gfp.h:
* Action modifiers - doesn't change the zoning * * __GFP_REPEAT: Try hard to allocate the memory, but the allocation attempt * _might_ fail. This depends upon the particular VM implementation. * * __GFP_NOFAIL: The VM implementation _must_ retry infinitely: the caller * cannot handle allocation failures. * * __GFP_NORETRY: The VM implementation must not retry indefinitely. */
- 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/
| |