| |||||||||||||
Fixing writeback from direct reclaimFixing writeback from direct reclaimPosted Jul 27, 2010 21:12 UTC (Tue) by giraffedata (subscriber, #1954)In reply to: Fixing writeback from direct reclaim by i3839 Parent article: Fixing writeback from direct reclaim
The page stealer does need memory itself. I've always hated the lack of strict resource ordering in Linux, such that it avoids deadlock only by parameters being set so that it's really unlikely, but that's the way it is. The kmalloc pool sits above and below many other layers. The page stealer is more complex than you're probably thinking, because it can involve, for example, writing the contents of a page to its backing store on a network filesystem. There is a flag (PF_MEMALLOC) on a memory request that says, "this request is part of memory allocation itself" or, equivalently, "don't wait for memory under any circumstance." The requester is supposed to have some way to respond to a failed memory allocation that is better than a deadlock. For example, it could try to find an easier page to steal. Page fault handling does happen in process context. It normally requires I/O, so interrupt context is pretty much out of the question. I remember a similar discussion some years ago, in which someone as an experiment set his minimum free list size to zero, and the system froze. Of course, everything here must be taken with a grain of salt because this stuff changes frequently, so what's true of one particular version of kernel isn't necessary true of another. I do remember being tormented by the network subsystem's requests for memory as part of page stealing and then someone later doing something to ameliorate that.
(Log in to post comments)
Fixing writeback from direct reclaim Posted Jul 28, 2010 19:01 UTC (Wed) by i3839 (guest, #31386) [Link]
Peter Zijlstra was busy with a VM deadlock prevention patch a while ago, no idea if that made it or if that PF_MEMALLOC flag came from there.
Anyway, those cases come from cleaning dirty pages, and the deadlock comes into view when that is triggered by the page stealer, but those paths try to allocate memory and trigger the page stealer again. I wouldn't really say the page stealer is the one needing memory, but rather that to steal dirty pages you sometimes need memory, especially with network file systems. The main problem there being that they need to receive packets to have forward progress in the dirty data writeout (and you don't know before receiving whether it's a critical packet or not). I think they added a memory pool to mostly fix this case.
Most page faults don't require IO, just memory mapping updates. If a process allocates memory it gets virtual memory, only when it actually uses it real memory is allocated for it. In that case a page fault occurs and a page needs to be allocated and mapped. Same for copy-on-write handling. Looking at the code it seems that the kernel just has to enable interrupts and can continue handling the page fault in process context without doing much special.
|
|||||||||||||