On Wed, Nov 24, 2021 at 07:14:47PM +0900, Dominique Martinet wrote:
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.
It matters in the sense that the total energy consumption will be higher. I don't think we should try to work around hardware issues at the level of individual programs trying to influence decisions. This can never work, except as a local hack for some issue.
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.
Brainfart, I was thinking about CPUSchedulingPolicy=. I think it would make sense to set CPUSchedulingPolicy=batch.
Zbyszek