Messages in this thread | | | Date | Sat, 21 Aug 2004 12:03:34 +1000 | From | Nick Piggin <> | Subject | Re: PF_MEMALLOC in 2.6 |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |