tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: vmem(9) (was Re: netbsd-6: pagedaemon freeze when low on memory)

Lars Heidieker <> 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]
>> 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

Home | Main Index | Thread Index | Old Index