Date: Sat, 09 Dec 2023 16:15:17 +0000 From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 275594] High CPU usage by arc_prune; analysis and fix Message-ID: <bug-275594-3630-0vsZLoXvve@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-275594-3630@https.bugs.freebsd.org/bugzilla/> References: <bug-275594-3630@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D275594 --- Comment #9 from Mark Johnston <markj@FreeBSD.org> --- > I thought you would say that; I almost thought of the same thing more tha= n 20 years ago while implementing the initial version of vnlru along with M= att Dillon :) > > The per-mountpoint / per-filesystem vnode design has at least two challen= ges: > > 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 y= et effective, under my key findings out of the first test in the descriptio= n: 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 d= oes nothing to address its targets; it may as well do nothing. Rate-limiting j= ust gets us closer to doing nothing, or I am misunderstanding something about t= he patch. Suppose that arc_prune is disabled outright. How does your test fare? --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-275594-3630-0vsZLoXvve>