Fatal trap 12: page fault panic with recent kernel with ZFS

Kip Macy kmacy at freebsd.org
Tue May 19 02:45:04 UTC 2009

On Mon, May 18, 2009 at 7:34 PM, Ben Kelly <ben at wanderview.com> wrote:
> On May 18, 2009, at 9:26 PM, Kip Macy wrote:
>> On Mon, May 18, 2009 at 6:22 PM, Adam McDougall <mcdouga9 at egr.msu.edu>
>> wrote:
>>> On Mon, May 18, 2009 at 07:06:57PM -0500, Larry Rosenman wrote:
>>>  On Mon, 18 May 2009, Kip Macy wrote:
>>>  > The ARC cache allocates wired memory. The ARC will grow until there is
>>>  > vm pressure.
>>>  My crash this AM was with 4G real, and the ARC seemed to grow and grow,
>>> then
>>>  we started paging, and then crashed.
>>>  Even with the VM pressure it seemed to grow out of control.
>>>  Ideas?
>>> Before that but since 191902 I was having the opposite problem,
>>> my ARC and thus Wired would grow up to approx arc_max until my
>>> Inactive memory put pressure on ARC making it shrink back down
>>> to ~450M where some aspects of performance degraded.  A partial
>>> workaround was to add a arc_min which isn't entirely successful
>>> and I found I could restore ZFS performance by temporarily squeezing
>>> down Inactive memory by allocating a bunch of it myself; after
>>> freeing that, ARC had no pressure and could grow towards arc_max
>>> again until Inactive eventually rose.  Reported to Kip last night
>>> and some cvs commit lists.  I never did run into Swap.
>> That is a separate issue. I'm going to try adding a vm_lowmem event
>> handler to drive reclamation instead of the current paging target.
>> That shouldn't cause inactive pages to shrink the ARC.
> Isn't there already a vm_lowmem event for the arc that triggers reclamation?

You're right,  there is. I had asked alc if there was a better way
than using the paging target and he suggested it. I hadn't looked to
see if it was already there because we've had such troubles.

> On the low memory front it seems like the arc needs a way to tell the pager
> to mark some vnodes inactive.  I've seen many cases where the arc size
> greatly exceeded the target, but it couldn't evict any memory because all
> its buffers were still referenced.  This seems to behave a little better
> with code that increments vm_pageout_deficit and signals the pageout daemon
> when the arc is too far above its target.  The normal buffer cache seems to
> do this as well when its low on memory.

Good point. Patches welcome. Otherwise I'll look in to it when I get the chance.


More information about the freebsd-current mailing list