From Newsgroup: muc.lists.freebsd.stable

On Sat, Sep 13, 2025 at 6:17rC>PM Garrett Wollman <wollman@bimajority.org> wrote:

<<On Sat, 13 Sep 2025 04:02:01 +0100, Graham Perrin <grahamperrin@gmail.com> said:

Also, might one of the following be a better alternative?

vfs.zfs.arc_free_target

I still won't claim to understand the arc sizing stuff, but it looks like
this one triggers reaping when it is greater than freemem. (It appears
to be in pages, not bytes.)
Once arc_available_memory() calculates "n" via
PAGESIZE * ((int64_t)freemem - zfs_arc_free_target) and returns it
as a negative value, arc_reap_cb_check() looks like it decides this
is the time to reap, so I think the code calls arc_reap_cb(), which
calls arc_kmem_reap_soon(), which calls kmem_cache_reap_now(),
which becomes a call to FreeBSD's uma_zone_reclaim(.., UMA_RECLAIM_DRAIN).
So, it looks like it will try fairly hard to maintain at least vfs.zfs.arc_free_target
pages in freemem.

vfs.zfs.arc.sys_free

This does seem to be useful too, but I haven't figured out what it does. Something to do with eviction, but I haven't figured it out yet.
I would like to here if fiddling with these helps w.r.t. Garrett's problem, rick

The former *sounds* like it might be a reasonable lever, although I
still feel like there's some sort of accounting issue here. I note on
my systems the latter is zero, but the former has a positive value
(which seems to be related to memory size).

-GAWollman

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2