Re: PF_MEMALLOC in 2.6

[Nick Piggin]

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.
-
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/