Zbigniew Jędrzejewski-Szmek wrote on Wed, Nov 24, 2021 at 09:23:37AM +0000:
The consequence of that is it takes much longer to complete because the clock is down: what previously normally took ~55s real for ~27s of CPU time now takes 7m10 for 85s of CPU time -- but honestly I don't care how long this takes if it's not noticeable, this is perfect. Thanks again!
That's a really long time… 55/27 s seems fairly standard, e.g. I get 43/22 s with a 256 GB SATA disk. But 440/85 s is quite a bit worse.
I really don't think it matters: this is a background job. If I want to refresh the locate database for a one-time thing, e.g. because I just updated a lot of files and look for something new, I'd run `sudo updatedb` not `sudo systemctl start plocate-updatedb`...
Steinar would you consider adding this to the upstream service file?
I don't think this qualifies as a good default. I would consider it a hack to fix a local hardware problem. Fans in a laptop simply must not be loud enough to be annoying.
Well, there's annoying and annoying - I'm sure it could be better but I can accept hearing laptop fans if it means I can build a kernel slightly faster (because getting more heat out means thermal throttle doesn't need to hold back as much); but I don't want to hear the fan at random times when I'm not doing anything, even if it's not a horrible sound.
Even for a fanless system, the fan itself won't be annoying, but say you want to compile something just as plocate has heated up the CPU and you'll get much lower performance for what you actually wanted to do at this time -- so it makes sense for real background stuff to stay close to idle. (I'm not sure how stuff like intel/amd's "turbo" mode works, but I believe it won't work if your cpu is hot, and I'd take this even for my servers or other non-noisy systems)
(Zbigniew, does systemd just ignore the setting on systems where cpu accounting has not been enabled? iirc some distros still have it off and upstream might want to provide defaults that work everywhere)
I would have suggested also adding Nice=5 or something but I don't think it's required with this.
I think that with IOSchedulingClass=idle, niceness doesn't matter anymore.
Hmm, I'm not sure what makes you think that. From what I can tell, if nice has been set, the ioprio will derive a value from it automatically (ionice = (nice + 20) / 5 for best effort, and also ioprio set to idle if set to SCHED_IDLE -- see include/linux/ioprio.h in the kernel)
I however don't see anything that would hint that the other way around is true, it really seems to be specific to the IO scheduler to me. I don't see anything in block/ioprio.c that would also affect task scheduling.
I'll grant you that if no IO can be done, the process will be stuck waiting for IO and not consume a lot of CPU, but that's not really the same as being niced.