Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 05 Jan 2024 17:29:36 +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-9i8QLbMMrq@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 #23 from Seigo Tanimura <seigo.tanimura@gmail.com> ---
(In reply to Mark Johnston from comment #1)

> > - vfs.vnode.vnlru.max_free_per_call=3D100000
> This value is 10 times larger than the default.  Why did you change this =
parameter?  What happens if you leave it at the default value?

Out of the tests so far, I now believe that the default value of
vfs.vnode.vnlru.max_free_per_call (10K) was chosen in order to polish the l=
oad
under the uncontrollable and unreasonable ARC pruning requests.

Now that the ARC pruning is precisely throttled for the efficient execution=
, it
should be all right to increase vfs.vnode.vnlru.max_free_per_call up to
vfs.vnode.param.limit and let ZFS determine the actual work load.=20
vnode_list_mtx is an expensive lock, so once we acquire it, we should prune=
 as
many vnodes as we can.

--=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-9i8QLbMMrq>