CPU_PRIORITY is a misnomer

[cmm]

What you specify this way is the nice value, not SCHED_FIFO/SCHED_RR priority.

But actually it would be neat to have the ability to venture beyond the SCHED_OTHER policy: like, say, assign SCHED_IDLE to compilers etc. instead of assuming niceness 19 plus idle i/o is low enough for everybody. Not sure about SCHED_RR/SCHED_FIFO, since those come with foot-guns attached, but maybe allow even those (not in the default config though). I wonder if this direction has ever been explored in this project?

[mmstick]

I've been hesitant to use the features for defaults but it wouldn't hurt to have the option. I figured that niceness and setting the I/O class to idle is good enough for the compiler processes and background daemons.

[cmm]

Tangentially, have you considered using, say, JSON for configuration instead of this RON awfulness? Not only would you gain the benefits of a stable format that is familiar, comes with actual tooling, and supporting which wouldn't cause periodic build breakage, but it would actually be more expressive, readable, and extendable. For example, one could be able to specify assignments like so:

{
    policies = {
        audio = {
            cpu = {
                class = "fifo";
                priority = 5;
            };
            io = {
                class = "best-effort";
                priority = 7;
            }
        };
        build = {
            cpu = {
                niceness = 19;
            };
            io = {
                class = "idle";
            };
        }
    };

    assignments = {
        audio = [ "pipewire" "pipewire-pulse" ];
        build = [ "gcc" "make" "ninja" ];
    }
}

(I mean one could do such policy/assignment split using RON too, but JSON would force one to and I think one would be all the better for it)