Re: PF_MEMALLOC in 2.6

[Nick Piggin <nickpiggin@yahoo.com.au>]

Oliver Neukum wrote:
> Am Donnerstag, 19. August 2004 14:41 schrieb Hugh Dickins:
> 
>>Fine for it to dip into those reserves when acting on behalf of something
>>already PF_MEMALLOC (i.e. try_to_free_pages itself), but not fine for it
>>to do so as a matter of course e.g. worst case, doing readahead could
>>easily exhaust reserves.  Or, is this thread only used for writing?
>>that wouldn't be so bad if so.
> 
> 
> All IO going to the actual disk uses the thread. However we usually
> don't want to fail IO request due to low memory.
> 

I'm with Hugh on this one. You only want to be PF_MEMALLOC when
you are in the process of cleaning some memory so it can be freed.
(Perhaps it would be more logical if it were called PF_MEMFREE, and
set in mm/vmscan.c, however the end result is the same)

So if this thing allocates memory on behalf of a read request, then
it is basically a bug. In practice you could probably get away with
servicing all writes with PF_MEMALLOC, however that could still lead
to situations where it consumes all your low memory on behalf of
highmem IO (though perhaps this won't deadlock if that memory is
going to be released as a matter of course?)

Another thing, having it always use PF_MEMALLOC means it can easily
wipe out the GFP_ATOMIC reserve.

So I'd say try to find a way to only use PF_MEMALLOC on behalf of
a PF_MEMALLOC thread or use a mempool or something.