Lars Heidieker <lars%heidieker.de@localhost> writes: > On 2013-03-18 20:08, Greg Troxel wrote: >> >> [discussion of pagedaemon having a tight loop when kmem is low but >> trying to free some isn't successful] >> >> http://mail-index.netbsd.org/tech-kern/2013/03/04/msg015063.html >> >> Lars has adjusted the default maxvnodes, which should help most people >> From avoiding the pagedaemon tight loop. But I think it still makes >> sense to apply Richard's patch, which should make the >> truly-out-of-memory situation behave a bit better, with many processes >> stuck waiting for memory, rather than the system locked up. >> >> It will remain to have more (and more effective) drain routines, and >> perhasp an out-of-memory killer. > > We might consider to install a pool cache drain hook for releasing vnodes. Sounds good, but I think installing this patch is separable from from adding better drain hooks. >> So if there are no objections, I'll commit Richard's patch (in the >> message linked above). > > One problem I see with the patch is, if applied the pagedaemon gives up > pool_draining after the first call to pool_drain that doesn't free > anything. pool_drain drains one and only one pool per call, so chance > are good that we stop to early. > > So we might want to install a callbak here that get's called under > uvm_km_va_starved_p which drains all pools until one returns memory or > there are no more pools to drain. If this doesn't free anything we might > stop busy-looping. This may be nitpicking, but given that structure of looping around and expecting to free something, and the need to avoid livelock, it seems like the draining multiple pools concept needs to be pushed into the pool_drain routine rather than expecting the caller to call it N times before giving up, where N is hard to know and could change. It seem easy enough to have pool_drain keep going until either it tried them all or freed something. That would make the top-level logic post-patch correct. This change could also be separable from the patch I posted - the resulting high-spl tight loop is very very hard to diagnose when you hit it.
Attachment:
pgp06pyOk7tE3.pgp
Description: PGP signature