Re: Machine unresponsive with cache_lock: blocked on... message

[Johannes Hofmann <johannes.hofmann@xxxxxx>]

Matthew Dillon <dillon@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?

Cheers,
Johannes