ZFS arc_reclaim_needed: better cooperation with pagedaemon

Artem Belevich fbsdlist at src.cx
Mon Aug 23 07:28:09 UTC 2010

Ah! After re-reading your first email and I think I've finally got
what you're saying -- with your change ARC would only start giving up
memory when pagedaemon is awake. Presumably once it's awake it will
also run through inactive list pushing some of it to cache. On the
other hand existing code voluntarily frees up memory even before
pagedaemon wakes up and does such a good job that pagedaemon
practically never wakes up and thus does not get to clean inactive

Can anyone test the patch on a system with mix of UFS/ZFS filesystems
and see if the change mitigates or solves the issue with inactive
memory excessively backpressuring ARC.

Overall I think that your proposed change seems to make sense to me.

If we could also deal with zone fragmentation issue you've written in
another thread, that should bring ZFS even closer to being usable
without shaman-style (the one with lots of muttering, swearing and
dancing around) tuning.

Actually, it may be worth trying your test with re-enabled UMA
allocator for ARC. Now that pagedaemon will be running, it would also
invoke UMA's low memory handlers and those should be able to give some
memory back to the system.


On Sun, Aug 22, 2010 at 11:12 PM, Andriy Gapon <avg at freebsd.org> wrote:
> on 23/08/2010 02:52 Artem Belevich said the following:
>> Do you by any chance have a graph showing kstat.zfs.misc.arcstats.size
>> behavior in addition to the stuff included on your graphs now?
> Yes, I do and not by a chance :-)
>> All I
>> can tell from your graphs is that v_free_count+v_cache_count shifted a
>> bit lower relative to v_free_target+v_cache_min.
> Don't belittle those graphs :-)
> Remember that the "fuchsia" line is when pagedaemon is woken up.
>> It would be
>> interesting to see what effect your patch has on ARC itself,
>> especially when ARC will start giving up memory and when does it stop
>> shrinking.
> In an extreme case it stops at arc_c_min as expected.  An extreme case is when
> userland application(s) demand a lot of memory fast.
> Now the graphs:
> http://people.freebsd.org/~avg/arc1.png
> http://people.freebsd.org/~avg/arc2.png
> http://people.freebsd.org/~avg/pages.png
> http://people.freebsd.org/~avg/arc3.png
> What do you see?  What do you think?
> --
> Andriy Gapon

More information about the freebsd-hackers mailing list