On Thu, 27 Jul 2023 at 13:24, Greg Troxel <g...@lexort.com> wrote: > > 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.)
I would definitely like to see something like this in-tree soonest for low memory (<6GB?) machines, but I'd prefer not to affect machines with large amounts of memory used as dedicated ZFS fileservers (at least not until its easily tunable) Thanks David