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

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

: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.
:
:-- 
: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.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>