No subject

Unknown Unknown
Sun Mar 21 12:14:44 PDT 2010

15643 at> <20100321190708.GA63881 at>
From: Matthew Dillon <dillon at>
Subject: Re: Machine unresponsive with cache_lock: blocked on... message
Date: Sun, 21 Mar 2010 12:14:11 -0700 (PDT)
List-Post: <mailto:bugs at>
List-Subscribe: <mailto:bugs-request at>
List-Unsubscribe: <mailto:bugs-request at>
List-Help: <mailto:bugs-request at>
List-Owner: <mailto:owner-bugs at>
Sender: bugs-errors at
Errors-To: bugs-errors at
Lines: 35
X-Trace: 1269198938 55375
Xref: dragonfly.bugs:11552

:>     Try setting it to 40 (it defaults to 23).  The max value is 64
:>     which will effectively put all non-memory-mapped file data on the
:>     inactive queue, including any data which is repeatedly accessed.
:Done. I raised it previously to 30 (I think) and still had a crash.
:FWIW, this machine is also running a postgres server.
:Francois Tigeot

    It wouldn't effect the crash condition, which was a low memory
    condition generated by cache+free followed by a deadlock.  The
    cycle point only effects active vs inactive.

    But raising the cycle point should reduce the degree by which
    active program memory is swapped out.  On the flip-side, the
    cost of doing this is that file data may be thrown out too quickly.
    That is, cacheable file data will be mixed in with uncacheable
    file data in the inactive queue and we'll be throwing the baby out
    with the dishwater, so to speak.

    Still, if this fixes the rdist / reblocking issue maybe we should just
    eat the early hucking of cached file data in favor program data not
    getting paged so aggressively, since people seem to notice when the
    latter happens a lot more.

    I'd like to know if this solves your particular problem (the paging
    issue, not the crashing issue), and if so I will change the default
    cycle point for the release.  So play with it.

					Matthew Dillon 
					<dillon at>

More information about the Bugs mailing list