Re: zfs pool behavior - is it ever freed?

[Greg Troxel <gdt%lexort.com@localhost>]

Tobias Nygren <tnn%NetBSD.org@localhost> writes:

> I use this patch on my RPi4, which I feel improves things.
> People might find it helpful.

That looks very helpful; I'll try it.

> There ought to be writable sysctl knobs for some of the ZFS
> tuneables, but looks like it isn't implemented in NetBSD yet.

That seems not that hard -- it would be great if someone(tm) did that
and mailed a patch.

> --- external/cddl/osnet/dist/uts/common/fs/zfs/arc.c	3 Aug 2022 01:53:06 -0000	1.22
> +++ external/cddl/osnet/dist/uts/common/fs/zfs/arc.c	27 Jul 2023 11:10:40 -0000
> @@ -6100,6 +6100,10 @@ arc_init(void)
>  	else
>  		arc_c_max = arc_c_min;
>  	arc_c_max = MAX(arc_c * 5, arc_c_max);
> +#if defined(__NetBSD__) && defined(_KERNEL)
> +/* XXX prevent ARC from eating more than 12% of kmem */
> +	arc_c_max = MIN(arc_c, vmem_size(heap_arena, VMEM_ALLOC | VMEM_FREE) / 8);
> +#endif
>
>  	/*
>  	 * In userland, there's only the memory pressure that we artificially

That seems eminently sensible and is sort of what I was thinking of
heading to.  Interesting q about /8 vs /16, but it's a reasonable enough
value to avoid lockups and that's 90% of the benefit.

I wonder if we should commit that as obviously better than where we are
now, where machines of <= 4G fail badly.

It would be interesting for people with 8G and 16G machines to try this
patch.  That will be somewhat less and maybe not less respectively.

Also perhaps a dmesg printout of what arc_c_max is set to, to help in
figuring things out.

(I suppose one can gdb it, too, for testing.)