DragonFly bugs List (threaded) for 2010-03
Re: Machine unresponsive with cache_lock: blocked on... message
:This machine was really fine running the same workload with 2.4.
:With 2.5, simple hammer cleanup or rsync commands are enough to make
:PCs with 2GB or 3GB memory swap.
The paging is due to a tradeoff for which there is no good answer.
In 2.4 we were holding 'old' cache data for much longer by trading
off against throwing away more recently cached data accessed only
once or twice. rsync and cleanup access data from the filesystem
but essentially in a single scan, so the data is accessed only once
and is thus subject being thrown away quickly.
However this also resulted in serious breakage for another class of
program which needs a large cached data set, for example if a machine
is distributing /usr/src and /usr/src fits in memory, the above code
would actually cause /usr/src to not get entirely cached and cause
disk activity on every scan even though there is enough memory to
The kernel can't really tell the difference between the desire to
cache a lot of data and a single-scan operation such as rdist or
hammer cleanup (and even then it has no idea whether the rdist
represents a data set small enough to be cached or not).
So its like half dozen of this or a half dozen of that... there is
no right answer. We would need something like an ARC cache for our
VM pages and vnodes to distinguish between the cases.