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,