lix-project/lix

Fork 59

Allow configuring niceness, ionice and similar settings for builders #1096

New issue

Open

opened 2026-01-06 21:37:06 +00:00 by 9ary · 6 comments

9ary commented

2026-01-06 21:37:06 +00:00

I alias verynice to schedtool -B -n 15 -e ionice -c3 (SCHED_BATCH, nice level of 15, "idle" IO scheduling class), which is useful to preserve system interactivity during long builds that hammer the CPU.
It's difficult to do this for unprivileged builds through the lix daemon.

Describe the solution you'd like

Options to set at least the properties supported by schedtool and ionice (from util-linux):

scheduler policy (only SCHED_BATCH seems to make sense here, a boolean is sufficient)
niceness
CPU affinity? (optional)
IO scheduling class (again, only idle really makes sense so a boolean is enough)
IO priority ("class data" in the manpage)

Describe alternatives you've considered

Although one could set these properties on the daemon itself, this feels incorrect and not very flexible. The daemon is also not used for builds invoked by root (e.g., nixos-rebuild).

Additional context

N/A

## Is your feature request related to a problem? Please describe. I alias `verynice` to `schedtool -B -n 15 -e ionice -c3` (SCHED_BATCH, nice level of 15, "idle" IO scheduling class), which is useful to preserve system interactivity during long builds that hammer the CPU. It's difficult to do this for unprivileged builds through the lix daemon. ## Describe the solution you'd like Options to set at least the properties supported by [schedtool](https://github.com/freequaos/schedtool) and ionice (from util-linux): - scheduler policy (only SCHED_BATCH seems to make sense here, a boolean is sufficient) - niceness - CPU affinity? (optional) - IO scheduling class (again, only idle really makes sense so a boolean is enough) - IO priority ("class data" in the manpage) ## Describe alternatives you've considered Although one could set these properties on the daemon itself, this feels incorrect and not very flexible. The daemon is also not used for builds invoked by root (e.g., nixos-rebuild). ## Additional context N/A

pennae commented

2026-01-06 21:42:45 +00:00

Owner

this is completely impossible in lix itself today due to protocol limitations, and it'll be Quite Some Time before we're in a place that would allow us to do this. setting the options on the daemon itself (or the systemd units, as nixos does by default to some extent) is the best thing we can offer today. with the cgroups experimental feature enabled you can also have a monitor running in the background that manipulates lix cgroups depending on how long a build have been active.

this is completely impossible in lix itself today due to protocol limitations, and it'll be Quite Some Time before we're in a place that would allow us to do this. setting the options on the daemon itself (or the systemd units, as nixos does by default to some extent) is the best thing we can offer today. with the `cgroups` experimental feature enabled you can also have a monitor running in the background that manipulates lix cgroups depending on how long a build have been active.

pennae added the

performance

E/requires rearchitecture

labels

2026-01-06 21:43:43 +00:00

9ary commented

2026-01-06 21:50:12 +00:00

Author

Fair enough, this is far from urgent and a reasonable workaround exists.

@pennae wrote in #1096 (comment):

protocol limitations

I'm not familiar with the internals at all. Out of curiosity, what's the limitation here?

Fair enough, this is far from urgent and a reasonable workaround exists. @pennae wrote in https://git.lix.systems/lix-project/lix/issues/1096#issuecomment-17106: > protocol limitations I'm not familiar with the internals at all. Out of curiosity, what's the limitation here?

pennae commented

2026-01-06 21:54:50 +00:00

Owner

I'm not familiar with the internals at all. Out of curiosity, what's the limitation here?

communicating literally anything to the daemon that isn't part of our established (and, for now, frozen) wire protocol, for example scheduling configuration for builds started by a specific client instance. we can't change it because that'd make us incompatible with cppnix including remote build servers and clients, so changing that is a a no go. a new rpc protocol is in the works though, and once that's done we can properly reconsider something like this

> I'm not familiar with the internals at all. Out of curiosity, what's the limitation here? communicating literally anything to the daemon that isn't part of our established (and, for now, frozen) wire protocol, for example scheduling configuration for builds started by a specific client instance. we can't change it because that'd make us incompatible with cppnix *including* remote build servers and clients, so changing that is a a no go. a new rpc protocol is in the works though, and once that's done we can properly reconsider something like this

9ary commented

2026-01-06 22:11:55 +00:00

Author

Ah right, thanks for explaining. Maybe I didn't explain my request very well.

I was expecting a set of nix.conf options, which unless I'm mistaken the daemon reads itself so this shouldn't be a problem? Lix already adds some of those (such as temp-dir), and they can also be overridden with --option (this is currently the only way to limit the number of cores used by a build at runtime, so it would at least be consistent), but I have no idea how this interacts with the protocol.

Ah right, thanks for explaining. Maybe I didn't explain my request very well. I was expecting a set of nix.conf options, which unless I'm mistaken the daemon reads itself so this shouldn't be a problem? Lix already adds some of those (such as temp-dir), and they can also be overridden with `--option` (this is currently the only way to limit the number of cores used by a build at runtime, so it would at least be consistent), but I have no idea how this interacts with the protocol.

pennae commented

2026-01-06 22:16:50 +00:00

Owner

every --option that passes from the cli to the daemon must go through the protocol, so we can't change the set of options the daemon sees for now. we could add some options to nix.conf that can't be overridden by clients, but at that point we're just badly reimplementing systemd :(

we also want more flexible resource configuration, scheduling options, monitorin, etc. it's on the list, but we won't get there very soon

every `--option` that passes from the cli to the daemon must go through the protocol, so we can't change the set of options the daemon sees for now. we could add some options to nix.conf that *can't* be overridden by clients, but at that point we're just badly reimplementing systemd :( we also want more flexible resource configuration, scheduling options, monitorin, etc. it's on the list, but we won't get there very soon

9ary commented

2026-01-06 22:21:13 +00:00

Author

alright that makes perfect sense, thanks again!