No subject

[Unknown]

8.GA1575 at sekishi.zefyris.com>
From: Matthew Dillon <dillon at apollo.backplane.com>
Subject: Re: Machine unresponsive with cache_lock: blocked on... message
Date: Sat, 20 Mar 2010 13:41:54 -0700 (PDT)
BestServHost: crater.dragonflybsd.org
List-Post: <mailto:bugs at crater.dragonflybsd.org>
List-Subscribe: <mailto:bugs-request at crater.dragonflybsd.org?body=subscribe>
List-Unsubscribe: <mailto:bugs-request at crater.dragonflybsd.org?body=unsubscribe>
List-Help: <mailto:bugs-request at crater.dragonflybsd.org?body=help>
List-Owner: <mailto:owner-bugs at crater.dragonflybsd.org>
Sender: bugs-errors at crater.dragonflybsd.org
Errors-To: bugs-errors at crater.dragonflybsd.org
Lines: 18
NNTP-Posting-Host: 216.240.41.25
X-Trace: 1269117830 crater_reader.dragonflybsd.org 55377 216.240.41.25
Xref: crater_reader.dragonflybsd.org dragonfly.bugs:11540


:Okay. Since this is not really something which can be resolved automatically,
:is there a way for the administrator to set a hard limit to the memory used
:by disk activity ?
:A sysctl such as kern.max_disk_cache or so ?
:
:-- 
:Francois Tigeot

    Being able to predict that a piece of data does not have to be cached
    for very long, such as when traversing a very large data set (rdist,
    rebalance, reblock) is what allows the rest of the data in the cache to
    remain in the cache.  This is not an easy prediction to make.  Something
    like an ARC implementation would do a better job making this prediction.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>