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)

On 2013-03-19 06:00, Lars Heidieker wrote:
On 2013-03-19 02:11, Greg Troxel wrote:
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,

I don't quite understand what do you mean by "those two cases". Do you mean (1) low on physical RAM (but not KVA), and (2) low on KVA (but not physical RAM)?


Home | Main Index | Thread Index | Old Index