Date: Mon, 23 Aug 2010 00:28:07 -0700 From: Artem Belevich <fbsdlist@src.cx> To: Andriy Gapon <avg@freebsd.org> Cc: freebsd-hackers@freebsd.org, zfs-devel@freebsd.org Subject: Re: ZFS arc_reclaim_needed: better cooperation with pagedaemon Message-ID: <AANLkTikg3e%2BGvZNtb5Uk3yAvWYwrgfF-4Rx0dDdooyQM@mail.gmail.com> In-Reply-To: <4C721161.40403@freebsd.org> References: <4C719AB9.9020006@freebsd.org> <AANLkTinreSt_Dk_J5vpZ6xrs=snqYu8zKfO0X6H-x_n3@mail.gmail.com> <4C721161.40403@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 list. 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. --Artem On Sun, Aug 22, 2010 at 11:12 PM, Andriy Gapon <avg@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. =A0An 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? =A0What do you think? > > -- > Andriy Gapon >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTikg3e%2BGvZNtb5Uk3yAvWYwrgfF-4Rx0dDdooyQM>