Date: Fri, 12 Jan 2024 03:10:31 +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-zLmMvgpUuu@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 #31 from Seigo Tanimura <seigo.tanimura@gmail.com> --- (In reply to Mark Johnston from comment #9) Now with the somewhat better answer: > 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 memo= ry. If arc_prune() is spending most of its time reclaiming tmpfs vnodes, t= hen it does nothing to address its targets; it may as well do nothing. Rat= e-limiting just gets us closer to doing nothing, or I am misunderstanding s= omething about the patch. The rate limiting in my fix now comes with the maximum and optimal workload= .=20 That is required because both the overcommit and undercommit of the ARC pru= ning waste the CPU time by the effortless vnode list lock and the overhead to ca= ll vnlru_free_impl(), respectively. The elimination of the giveups in vnlru_free_impl() and the prunable znodes under zfs_arc_dnode_reduce_percent are the positive evidences. The pileup of the ARC metadata with no evictable portion should still be investigeted, as that is the direct cause of the out-of-control ARC pruning requests. The unevictable ARC content is caused by the ZIO on it, but it is not clear how the ZIO keeps running so long. --=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-zLmMvgpUuu>