DragonFly BSD
DragonFly bugs List (threaded) for 2010-03
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

[no subject]


From: Matthew Dillon <dillon@apollo.backplane.com>
Subject: Re: Machine unresponsive with cache_lock: blocked on... message
Date: Sat, 20 Mar 2010 13:46:22 -0700 (PDT)
BestServHost: crater.dragonflybsd.org
List-Post: <mailto:bugs@crater.dragonflybsd.org>
List-Subscribe: <mailto:bugs-request@crater.dragonflybsd.org?body=subscribe>
List-Unsubscribe: <mailto:bugs-request@crater.dragonflybsd.org?body=unsubscribe>
List-Help: <mailto:bugs-request@crater.dragonflybsd.org?body=help>
List-Owner: <mailto:owner-bugs@crater.dragonflybsd.org>
Sender: bugs-errors@crater.dragonflybsd.org
Errors-To: bugs-errors@crater.dragonflybsd.org
Lines: 24
X-Trace: 1269118054 crater_reader.dragonflybsd.org 55375
Xref: crater_reader.dragonflybsd.org dragonfly.bugs:11541

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

					Matthew Dillon 

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]