Re: upcoming kerneloops.org item: get_page_from_freelist

[Nick Piggin]

On Thu, Jun 25, 2009 at 01:22:25PM -0700, Linus Torvalds wrote:
> 
> 
> On Thu, 25 Jun 2009, Linus Torvalds wrote:
> > 
> > Whether these are important to you or not, I dunno. I actually suspect 
> > that we might want a combination of "high priority + allow memory 
> > freeing", which would be
> > 
> > 	#define GFP_CRITICAL (__GFP_HIGH | __GFP_WAIT)
> 
> Actually, that doesn't work quite the way I intended.
> 
> The current page allocator screws up, and doesn't allow us to do this 

No I think it works OK. As designed, at least (whether or not
you agree with the design :P)


> (well, you _can_ combine the flags, but they don't mean what they mean on 
> their own). If you have the WAIT flag set, the page allocator will not set 
> the ALLOC_HARDER bit,

But it does use ALLOC_HIGH.


> so it turns out that GFP_ATOMIC (__GFP_HIGH on its 
> own) sometimes actually allows more allocations than the above 
> GFP_CRITICAL would.

Yes. The intention was to allow allocations from sleepable/reclaimable
context but not allow them to use up all the reserves allowed for
atomic context (so you don't suddenly get bursts of atomic allocation
failure warnings on your network card when under heavy disk IO, for
example).

 
> It might make more sense to make a __GFP_WAIT allocation set the 
> ALLOC_HARDER bit _if_ it repeats. The problem with doing a loop of 
> allocations outside of the page allocator is that you then miss the 
> subtlety of "try increasingly harder" that the page allocator internally 
> does (well, right now, the "increasingly harder" only exists for the 
> try-to-free path, but we could certainly have it for the try-to-allocate 
> side too)
--
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/