DragonFly bugs List (threaded) for 2010-03
From: Matthew Dillon <email@example.com>
Subject: Re: Machine unresponsive with cache_lock: blocked on... message
Date: Sun, 21 Mar 2010 12:14:11 -0700 (PDT)
X-Trace: 1269198938 crater_reader.dragonflybsd.org 55375 126.96.36.199
Xref: crater_reader.dragonflybsd.org 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.
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.