l2arc_feed_thread cpu utlization

Andriy Gapon avg at FreeBSD.org
Fri Feb 14 11:53:51 UTC 2014


on 19/12/2013 13:30 Andriy Gapon said the following:
> 
> This is just a heads up, no patch yet.
> 
> l2arc_feed_thread periodically wakes up and scans certain amount of ARC buffers
> and writes eligible buffers to a cache device.
> Number of scanned buffers is limited by a threshold on the amount of data in the
> buffers seen.  The threshold is applied on a per buffer list basis.  In upstream
> there are 4 relevant lists: (data, metadata) X (MFU, MRU).  In FreeBSD each of
> the lists was subdivided into 16 lists.  This was done to reduce contention on
> the locks that protect the lists.  But as a side effect l2arc_feed_thread can
> scan 16 times more data (~ buffers).
> 
> So, if you have a rather large ARC and L2ARC and your buffers tend to be
> sufficiently small, then you could observe l2arc_feed_thread burning a
> noticeable amount of CPU.  On some of our systems I observed it using up to 40%
> of a single core.  Scaling back the threshold by factor of 16 makes CPU
> utilization go down by the same factor.
> 
> I plan to commit this change to FreeBSD ZFS code.
> Any comments are welcome.

Here is what I have in mind:
https://github.com/avg-I/freebsd/compare/wip;hc;l2arc_feed_thread_scan_rate

The calculations in the macro look somewhat ugly, but they should be correct :-)

-- 
Andriy Gapon


More information about the freebsd-fs mailing list