Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nix-daemon: Add CPU and IO weight options #26520

Closed
wants to merge 2 commits into from
Closed

Conversation

Baughn
Copy link
Contributor

@Baughn Baughn commented Jun 11, 2017

Motivation for this change

Making Chrome (or other UI elements) less laggy.

CPU prioritization by way of 'nice' doesn't work very well. Modern systems have a better option, in that systemd can be used to set CPU timeslice weighting explicitly. This requires turning on accounting for the same, globally across the system, which I do with the systemd config patch.

The second patch makes the CPU weighting configurable for the nix-daemon service, and defaults it to the minimum possible. I believe this is a good default for desktop systems, as well as most servers; the builds are generally batch processes, and this setting does not prevent it from using all idle time.

All of the above is duplicated for I/O accounting, although I cannot test the impact from this due to running on NVMe.

There is a very slight performance impact from the accounting, but not so you'd notice. My experience is that it (if it exists at all) is vastly outweighed by usability improvements through making interactive sessions higher priority.

(I've been told that CPU and I/O accounting has low impact, while memory accounting has medium. This patch does not enable memory accounting.)

Other batch services should probably get the same treatment.

Things done
  • Tested using sandboxing
    (nix.useSandbox on NixOS,
    or option build-use-sandbox in nix.conf
    on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • Linux
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Fits CONTRIBUTING.md.

@mention-bot
Copy link

@Baughn, thanks for your PR! By analyzing the history of the files in this pull request, we identified @edolstra, @MarcWeber and @abbradar to be potential reviewers.

@grahamc
Copy link
Member

grahamc commented Jun 11, 2017

Fwiw the nix daemon should be prioritized like a user facing application, because indeed for operations likenix-shell it is a user facing. I set the process priority too low on macOS and found my nix-shell would take 5 minutes to execute, compared to just seconds before. Somewhere in the middle is probably best.

@Baughn
Copy link
Contributor Author

Baughn commented Jun 11, 2017

20% by default, maybe?

I don't know about OSX, but using CPUWeight it'll still use any idle capacity. I'm not seeing any effect on shell usage, but... hmm, this is hard. Ideally it'd depend on which window is in focus.

@@ -725,6 +725,8 @@ in

"systemd/system.conf".text = ''
[Manager]
DefaultCPUAccounting=yes
DefaultBlockIOAccounting=yes
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BlockIOAccounting refers to the legacy cgroup hierarchy (while IOWeight used above belongs to the unified hierarchy).

The way I read the manual, this is strictly redundant: enabling a type of resource control for one unit is said to imply enabling it for the slice it runs in and all parent slices.

Copy link
Contributor Author

@Baughn Baughn Jun 11, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When testing on my own system, the CPU accounting didn't seem to work without this setting. (But worked just fine even though I accidentally put it in user.conf instead of system.conf the first time, so I'm not sure what's going on.)

I can't test the IO accounting, you may well be right about that. What should I be using instead? My manual (man systemd-system.conf) just lists this one.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All the BlockIO* directives are now just IO*, so you can use DefaultIOAccounting.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@edolstra
Copy link
Member

edolstra commented Jun 12, 2017

I feel that we should not provide per-service options that duplicate systemd resource management functionality, because then we could potentially be adding hundreds of such options. Instead users should just use the systemd options, e.g.

systemd.services.nix-daemon.serviceConfig.CPUWeight = 123;

(nix.daemonNiceLevel is a legacy option that predates systemd, necessary because we had no such mechanism for Upstart jobs.)

I have no strong feelings about turning on accounting by default, but if it's not the upstream default, then maybe we shouldn't.

BTW, according to the systemd docs, CPUWeight and IOWeight require the unified control group hierarchy. But, AFAIK, we don't enable that yet. (But maybe it works in the hybrid mode, which is the systemd 233 default, I think.)

@Mic92
Copy link
Member

Mic92 commented Jun 12, 2017

If CPUWeight is enabled for one service, it will be enabled for all other services as well. This would mean that enabling this in nix-daemon will basically enable it for everyone globally. At the moment CPU controller support is not possible without out-of-tree patches according to this document: https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html#CPU

@Baughn
Copy link
Contributor Author

Baughn commented Jun 12, 2017

I feel that we should not provide per-service options that duplicate systemd resource management functionality, because then we could potentially be adding hundreds of such options. Instead users should just use the systemd options, e.g.

@edolstra My reasoning for adding the option is that without it, the default experience for NixOS is that the rest of the system gets laggy while nix-build is running. Which can happen as part of auto-updates.

I have no objection to using common options, but I feel that any such solution ought to have the same defaults as this patch.

@joachifm
Copy link
Contributor

@Baughn see also previous discussion at #22672

@edolstra
Copy link
Member

@joachifm Hah, I thought I commented on a similar PR recently but I couldn't find it :-)

@Baughn I don't object to setting some default values for CPUWeight etc. That's a separate issue from whether to add options.

@Baughn
Copy link
Contributor Author

Baughn commented Jun 15, 2017

@edolstra So let's talk interfaces.

The reason I'd like to add the options is so people will know they exist, and because there already is a niceness option there. With reasonable defaults that becomes less important, but my first thought on seeing "Huh, nix-build is eating all my CPU time" was to look for options relating to nix-build, not systemd.

On the other hand, long-term it would be good if systemd is the first place people look. It just isn't the case yet, since we haven't had these tools for very long.

How would you feel if, as a compromise:

  • I still add the option, with the same 20% default as in the current patch, but as an alias to the direct systemd option. I think it's too early to expect people to otherwise find it.
  • Optionally, I can deprecate and later remove the niceness option.

@0xABAB
Copy link
Contributor

0xABAB commented Jun 29, 2017

If you are just a user of the system and don't know anything about NixOS, you want it to run the daemon in such a way that you never notice it.

If you are a user who wants to use nix-shell, because you want to develop something and you are waiting for the answer, you want it to be done as fast as possible.

Any design which doesn't meet these two use cases is a design that isn't worth implementing.

@FRidh FRidh changed the title Nix daemon nix-daemon: Add CPU and IO weight options Jul 27, 2017
@Ekleog
Copy link
Member

Ekleog commented Oct 2, 2018

(triage) @edolstra, do you have an answer for #26520 (comment) ?

@Baughn
Copy link
Contributor Author

Baughn commented Oct 19, 2018

FWIW, since I upgraded to a TR4 1950X, I am no longer able to test this patch. For other reasons[1] I cannot configure Nix such that it ever uses the full CPU capacity of my machine.

[1] Specifically, the build daemon uses a ton of memory. So do compilers, etc. 32GB of memory isn't enough to gain 32-way parallelism in the builds; I have to configure it with a max of 12 threads.

@infinisil
Copy link
Member

If people have a hard time knowing that they can just use systemd.* directly to customize these options, then we should make better documentation for it. We shouldn't add duplicate options for increased visibility, this only increases evaluation time for no reason.

@infinisil
Copy link
Member

Closing this due to reasons mentioned above, see #26520 (comment) for how to do it without this option.

@infinisil infinisil closed this Nov 10, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

10 participants