Re: PF_MEMALLOC in 2.6

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

Alan Cox wrote:
> On Fri, Aug 20, 2004 at 04:50:07PM +0200, Oliver Neukum wrote:
> 
>>>This is what made me suspect that it's the diry memory writeout problem.
>>>It's just like how it was on 2.4 before Alan added PF_MEMALLOC.
>>
>>If we add PF_MEMALLOC, do we solve the issue or make it only less
>>likely? Isn't there a need to limit users of the reserves in number?
> 
> 
> PF_MEMALLOC won't recurse. You might run out of memory however. The old
> world scsi drivers run in the thread of the I/O so are protected already
> by PF_MEMALLOC in those cases, its the thread nature of the USB driver which
> makes it more fun. Unless 2.6 vm is radically different I think PF_MEMALLOC
> is the right thing to set although it would always eventually be better to
> find out who is guilty of the blocking allocation that recurses.
> 
> Are any of the VM guys considering PF_LOGALLOC so you can trace it down 8)
> 
> 

The problem isn't necessarily a recursing allocation - although that
wouldn't be helping. The main thing is an inversion in the PF_MEMALLOC
reserve logic.

Memory goes below pages_min, thread A is in the allocator, sets
PF_MEMALLOC and tries to clean some pages. The USB thread then can't
allocate memory to service these requests because it is not PF_MEMALLOC.

If you make the USB thread PF_MEMALLOC, you solve this problem at the
cost of making the PF_MEMALLOC reserve more fragile. If you're pretty
sure that it only allocates a small, bounded amount of memory then that
may be a good enough fix for now.