Brad Spencer <[email protected]> writes: > Sotiris Lamprinidis<[email protected]> writes: > >> I looked into exposing ZFS tunables through sysctl and it seems >> straightforward. Despite being under "dist" I am not sure if this is true >> upstream, so the patch is directly on arc.c (and I think it'd be tricky to >> implement otherwise). >> >> I tested arc_min and arc_max, and it seems like changes do have an effect >> (e.g. on c, c_max). Additionally tested arc_free_target and it does have >> an effect also. > > Thank you very much for this patch.
I'm not sure where we are on merging this patch. I think it's useful for people to be able to set and observe these tunables. It seems to be that patching arc.c is fine. The concept of upstream is a bit messy. > I have been struggling with ZFS on a 8 to 16GB DOMU build system for > quite a while and with this patch and setting the values to what you > have listed I was able to perform my abuse builds without any problems > at all. 100% workable with 4 parallel builds all using the 2 CPUs I > give to the DOMU. Before this I could do one or two full system > builds before I would have to reboot the build box and I was pretty > much unable to do more than 2 parallel builds at a time without > locking the system up. Clamping the size of the ARC seems to be the > key. One work around I was trying to use was setting the maxvnodes to > a very low value and that work around could be removed as well. > I am running this on a -current as of 2026-07-15. This find is very > much appreciated. Thanks again. Interesting that you are still having lockups on current. It has a lot of locking fixes (also in 11, not in 10). My guess is that reducing arc is a workaround, not a fix, and is avoiding the locking bugs by leaving more free. Still, not crashing is good.... I don't mean to say we shouldn't merge the patch, or that it isn't helpful to be able to set/observe -- only that there is deeper trouble.
