kern/187594: [zfs] [patch] ZFS ARC behavior problem and fix

dteske at dteske at
Mon Apr 14 18:00:01 UTC 2014

The following reply was made to PR kern/187594; it has been noted by GNATS.

From: <dteske at>
To: <bug-followup at>, <karl at>
Subject: Re: kern/187594: [zfs] [patch] ZFS ARC behavior problem and fix
Date: Mon, 14 Apr 2014 10:58:09 -0700

 Been running this on stable/8 for a week now on 3 separate machines.
 All appears stable and under heavy load, we can certainly see the new
 reclaim firing early and appropriately when-needed (no longer do we
 have programs getting swapped out).
 Interestingly, in our testing we've found that we can force the old
 reclaim (code state prior to applying Karl's patch) to fire by sapping the
 few remaining pages from unallocated memory. I do this by exploiting
 a little known bug in the bourne-shell to leak memory (command below).
 	sh -c 'f(){ while :;do local b;done;};f'
 Watching "top" in the un-patched state, we can see Wired memory grow
 from ARC usage but not drop. I then run the above command and "top"
 shows an "sh" process with a fast-growing "SIZE", quickly eating up about
 100MB per second. When "top" shows the Free memory drop to mere KB
 (single pages), we see the original (again, unpatched) reclaim algorithm
 and the Wired memory finally starts to drop.
 After applying this patch, we no longer have to play the game of "eat
 all my remaining memory to force the original reclaim event to free up
 pages", but rather the ARC waxes and wanes with normal applicate usage.
 However, I must say that on stable/8 the problem of applications going to
 sleep is not nearly as bad as I have experienced it in 9 or 10.
 We are happy to report that the patch seems to be a win for stable/8 as
 well because in our case, we do like to have a bit of free memory and the
 old reclaim was not providing that. It's nice to not have to resort to
 tricks to
 get the ARC to pare down.
 The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.

More information about the freebsd-fs mailing list