Machine unresponsive with cache_lock: blocked on... message
johannes.hofmann at gmx.de
Sat Mar 20 14:26:00 PDT 2010
375$415eb37d at crater_reader.dragonflybsd.org> <201003202046.o2KKkMwD005436 at 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
X-Trace: 1269119628 crater_reader.dragonflybsd.org 55375 184.108.40.206
Xref: crater_reader.dragonflybsd.org dragonfly.bugs:11542
Matthew Dillon <dillon at 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?
> 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.
More information about the Bugs