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

[Lars Heidieker <lars%heidieker.de@localhost>]

On 2013-03-19 02:11, Greg Troxel wrote:
> 
> 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.
> 

This is an option and looks better to me, a slight downside is we will
get more aggressive on pool draining in the normal case (non kva
shortage but physical ram) we used to drain one pool in a roundrobin way
with the change we drain until we actually drain something so we will
trade slightly higher cpu overhead for less unsued memory when there are
a lot not drainable pools around which is likely in such situations.
Well one could see this as an advantage as well.
(there is a timeout in the pool for empty items, so no "ping pong")

The question that remains is should we seperate those two cases, if not
your suggestion is just right.
We could simplify on the waiting in uvm_pageout then:
remove the kmem_va_starved from the if around UVM_UNLOCK_AND_WAIT
and check for uvm_km_va_starved once after wakeup and if true call (the
changed) pool_drain.
If we figure out we should seperate those cases, I'll make a callback
chain for the kva case and we switch pool_drain back to it's old behaviour.

In both cases we might want to include a check if the starvation
persists during draining and continue if so.

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

The problem is we can't progress without freeing something, not
busylooping might give the chance to free something, so is slightly
better I guess.

serach for uvm_kick_pdaemon that's what wakes it up.


Lars


-- 
------------------------------------

Mystische Erklärungen:
Die mystischen Erklärungen gelten für tief;
die Wahrheit ist, dass sie noch nicht einmal oberflächlich sind.

   -- Friedrich Nietzsche
   [ Die Fröhliche Wissenschaft Buch 3, 126 ]