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

[Johannes Hofmann <johannes.hofmann@xxxxxx>]

375$415eb37d@crater_reader.dragonflybsd.org> <201003202046.o2KKkMwD005436@apollo.backplane.com>
User-Agent: tin/1.9.4-20090211 ("Rieclachan") (UNIX) (DragonFly/2.5.1-DEVELOPMENT (i386))
Date: 20 Mar 2010 21:13:48 GMT
Lines: 33
NNTP-Posting-Host: 88.64.67.189
X-Trace: 1269119628 crater_reader.dragonflybsd.org 55375 88.64.67.189
Xref: crater_reader.dragonflybsd.org dragonfly.bugs:11542

Matthew Dillon <dillon@apollo.backplane.com> wrote:
> 
> :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
> 
>    You couldn't ^C the reblock?  Reblocking works the storage system
>    pretty heavily, performance issues are not necessarily going to be
>    related to paging activity.  Anything which has to read from disk will
>    be slow.
> 
>    How does the system know what pages are idle and what pages are not
>    idle when the whole system is idle?  How can the system distinguish
>    between the one-time scan that the reblocker does verses, say, someone
>    rdist'ing a dataset which would easily fit in memory that we DO want
>    to cache?

^C did succeed, but it took quite long - no lockup though.
It's understood, that all disk IO will be slow. I was just surprised
that the system uses swap in this case at all. Why should the system
move data out to swap to make place for the disk cache - at least if
swap does not happen to be on SSD?
I would have thought that only memory not otherwise needed is used to
cache disk data.

I will retry with swap disabled completely.

   Johannes