[Bug 275594] High CPU usage by arc_prune; analysis and fix

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275594

--- 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 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.

The rate limiting in my fix now comes with the maximum and optimal workload. 
That is required because both the overcommit and undercommit of the ARC pruning
waste the CPU time by the effortless vnode list lock and the overhead to call
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.