Tobias Nygren <t...@netbsd.org> 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.)