Fixing writeback from direct reclaim
Posted Jul 27, 2010 21:12 UTC (Tue) by giraffedata
In reply to: Fixing writeback from direct reclaim
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.
to post comments)