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 <lars%heidieker.de@localhost> writes:

> 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.

(I realize the patch Richard posted has some -6/-current issues in
naming, calling pool_drain_end instead of pool_drain.  I am fixing them;
I was going to do a test build and boot the modified kernel before
commiting.)

Reading your note again, I might have replied too quickly.  Two
questions:

How hard do you think it would be to make pool_drain() keep trying pools
until one succeeded in freeing something (or it tried them all)?  Do you
see any downside in that change?  It seems like it's just as well to
more aggressively try to free memory when we are out.  If a pool frees
something, it will stop, so it's only when pools do not give back any
space that it will take longer.   The round-robin nature seems to be
built in.  It seems perhaps tricky to retain the round-robin nature and
allow a full cycle; it's not obvious to me that just remembering the
current next pointer is ok, but I think it is.

Do you think that the patch's change to sleep after a failed drain will
cause a system to behave particularly badly?  It's not clear to me how
the pagedaemon gets woken up, and if it requires a new lwp to be wanting
memory.

Attachment: pgpBN9bQEMFgq.pgp
Description: PGP signature



Home | Main Index | Thread Index | Old Index