[Bug 275594] High CPU usage by arc_prune; analysis and fix
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sat, 09 Dec 2023 16:15:17 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275594 --- Comment #9 from Mark Johnston <markj@FreeBSD.org> --- > I thought you would say that; I almost thought of the same thing more than 20 years ago while implementing the initial version of vnlru along with Matt Dillon :) > > The per-mountpoint / per-filesystem vnode design has at least two challenges: > > A) Balancing the vnodes across the mountpoints / filesystems, and > B) Splitting the name cache. > > I suspect B) is the more difficult one. As of now, the global name cache allows the vnode lookup in a single place with just one pass. I'm not a VFS expert by any means, but I don't see what this has to do with the name cache. vnodes live on a global list, chained by v_vnodelist, and this list appears to be used purely for reclamation. Suppose we instead use a per-mountpoint LRU (and some strategy to select a mountpoint+num vnodes to reclaim) instead. How would this affect the name cache? > The interval between the ARC pruning executions is much more simple and yet effective, under my key findings out of the first test in the description: Sorry, I don't understand. The trigger for arc_prune is whether the ARC is holding "too much" metadata, or ZFS is holding "too many" dnodes in memory. If arc_prune() is spending most of its time reclaiming tmpfs vnodes, then it does nothing to address its targets; it may as well do nothing. Rate-limiting just gets us closer to doing nothing, or I am misunderstanding something about the patch. Suppose that arc_prune is disabled outright. How does your test fare? -- You are receiving this mail because: You are the assignee for the bug.