Re: Default autogroup niceness of Guix build daemon

[J. R. Haigh (re. Guix)]

Hi Giovanni,

At 2020-01-27Mon18:37:53+01, Giovanni Biscuolo sent:
> […]
> Since Debian 9 [uses] systemd, should be possible by configuring a limit in 
> the systemd service unit file [1]; I've never tried but try adding 
> "LimitNICE=19" in the [Service] stanza.

Thanks for the suggestion. I tried it and it seemed to only affect process 
niceness, not autogroup niceness. Htop reported process niceness values of 19 
on the relevant processes, and I already knew that setting these manually from 
Htop does not fix the lag. Autogroup niceness still defaults to 0:

$ (for P in $(ps --group="guixbuild" --format="pid="); do 
F="/proc/$P/autogroup"; echo "$F"; cat "$F"; done)
/proc/26741/autogroup
/autogroup-12141 nice 0

> Documentation on that parameter here:
> https://www.freedesktop.org/software/systemd/man/systemd.exec.html#Process%20Properties

Thank you. There does not seem to be anything on autogroup niceness there, 
which is apparently deliberate, unfortunately. I also tried ‘LimitNICE=+19’ and 
‘CPUSchedulingPolicy=idle’ but neither prevented Guix builds from hogging the 
CPU. As well as reloading the SystemD configuration, I also tried interrupting 
the build and starting it again, but the lag returned as soon as the build got 
going again.
        As a temporary workaround, I tried disabling CFS's autogrouping feature 
with:

sudo tee /proc/sys/kernel/sched_autogroup_enabled <<<0

…but it did not seem to do anything, despite Htop reporting that the relevant 
processes have a process niceness of 19. It seems that autogrouping is still 
enabled, despite the attempt to disable it, because the command in my previous 
email (repeated below) to imperatively change the autogroup niceness (to 19 and 
then back to 0) continues to have unmistakable effect on interactivity. As all 
other attempts so far have had no noticeable effect, that command remains to be 
the only workaround so far:

$ (for P in $(ps --group="guixbuild" --format="pid="); do 
F="/proc/$P/autogroup"; echo "$F"; cat "$F" && sudo tee "$F" <<<19; done)
/proc/26741/autogroup
/autogroup-12141 nice 0
[sudo] password for JRHaigh: 
19
$ (for P in $(ps --group="guixbuild" --format="pid="); do 
F="/proc/$P/autogroup"; echo "$F"; cat "$F" && sudo tee "$F" <<<0; done)  ##
/proc/26741/autogroup
/autogroup-12141 nice 19
0
$ (for P in $(ps --group="guixbuild" --format="pid="); do 
F="/proc/$P/autogroup"; echo "$F"; cat "$F" && sudo tee "$F" <<<19; done)
/proc/26741/autogroup
/autogroup-12141 nice 0
19

These cammands very clearly made my system responsive, laggy, and then 
responsive again, which was totally unexpected seeing as I had supposedly 
disabled autogrouping. Given that there are reasons why autogrouping was added 
and has been default on most/many distros for many years, it would be best if 
the solution worked with autogrouping enabled anyway, so I don't really want to 
waste time investigating why autogrouping does not seem to get disabled.
        Are there any modifications that could be made to the Guix daemon to 
fix this? Seeing as SystemD apparently does not support autogroup niceness, 
perhaps the next best alternative is to fix the CPUSchedulingPolicy setting. 
I'm guessing that it only affects the Guix daemon and does not cascade to its 
builders. Fixing the CPUSchedulingPolicy setting might provide a decent, 
declarative solution for build deprioritisation that could be used instead of 
niceness.

Regards,
James R. Haigh.
-- 
4 days, 5 hours, and 4 minutes left until FOSDEM 2020 (Saturday)!
5 days, 5 hours, and 4 minutes left until FOSDEM 2020 (Sunday)!
Wealth doesn't bring happiness, but poverty brings sadness.
https://wiki.FSFE.org/Fellows/JRHaigh
Sent from Debian with Claws Mail, using email subaddressing as an alternative 
to error-prone heuristical spam filtering.