[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Default autogroup niceness of Guix build daemon
From: |
J. R. Haigh (re. Guix) |
Subject: |
Re: Default autogroup niceness of Guix build daemon |
Date: |
Tue, 28 Jan 2020 03:56:17 +0000 |
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.