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