On Tue, Nov 07, 2023 at 12:50:33AM -0800, Christoph Hellwig wrote: > On Thu, May 25, 2023 at 06:55:18PM -0700, Darrick J. Wong wrote: > > From: Darrick J. Wong <djwong@xxxxxxxxxx> > > > > Currently, the xfs_scrub background service is configured to use -b, > > which means that the program runs completely serially. However, even > > using 100% of one CPU with idle priority may be enough to cause thermal > > throttling and unwanted fan noise on smaller systems (e.g. laptops) with > > fast IO systems. > > > > Let's try to avoid this (at least on systemd) by using cgroups to limit > > the program's usage to 60% of one CPU and lowering the nice priority in > > the scheduler. What we /really/ want is to run steadily on an > > efficiency core, but there doesn't seem to be a means to ask the > > scheduler not to ramp up the CPU frequency for a particular task. > > > > While we're at it, group the resource limit directives together. > > Een 60% sounds like a lot to me, at least for systems that don't have > a whole lot of cores. Of course there really isn't any good single > answer. But this is probably a better default than the previous one, Agreed, CPUQuota is an overbroad knob. On my 40-core servers, 60% of one CPU is very feeble and scrubs could actually go faster. For laptops and NUCs, 60% was the figure I came up with by running xfs_scrub on all the laptops and NUCs I could find, and ratcheting down the cpu usage until just below the point where the fans would speed up and/or stuttering was no longer noticeable. I pulled out some ancient craptops for that one. On a Pentium III 700 with 256M of RAM and a slow PATA SSD the experience wasn't any more terrible than you'd expect from that era of machine. That may become moot if Debian 13 drops support for bare metal i386. > so: > > Reviewed-by: Christoph Hellwig <hch@xxxxxx> Thanks for the reviews! --D
