Machine unresponsive with cache_lock: blocked on... message
johannes.hofmann at gmx.de
Sat Mar 20 13:30:43 PDT 2010
Matthew Dillon <dillon at apollo.backplane.com> wrote:
> :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.
I'm also seeing this.
> :Francois Tigeot
> 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
> cache it.
> 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.
Hm, I understand if hammer cleanup removes other data from cache, but
why should the disk cache usage push out data to swap?
I just tried a hammer cleanup on a completely idle system with 1.5G
memory in single user mode, and during the reblocking it started to
use swap and became unresponsive - is this really working as expected?
More information about the Bugs