Only the main thread of a process gets reniced properly if the process had a manual niceness assignment

[techsy730]

Say a program foo starts and then spawns 3 more threads.

And in /etc/system76-scheduler/assignments/foo.ron

{
  3: [
    "foo",
  ],
}

Then unless system76-scheduler happened to renice before the threads spawned, only main thread of foo is assured to be reniced to 3. The other threads would be left at the original niceness (typically 0, or 5 if it matched the background process renicing and that is enabled as well)

Reproduction

Add to some assignment .ron file

{
  -4: [
        "gnome-system-monitor",
],
}

Start gnome-system-monitor

Look at the niceness of the threads. The command ps -L -o pid,comm,lwp,nice --pid $(pidof gnome-system-monitor) should do it.

See how most likely only the main thread is at niceness -4, and the others remain at 0 niceness.

On my machine, the output was

    PID COMMAND             LWP  NI
 370993 gnome-system-mo  370993  -4
 370993 gmain            370995   0
 370993 dconf worker     370996   0
 370993 gdbus            370997   0

[techsy730]

Yet another way the LWP (basically, the thread's PID) being the "true" PID was, in the long run, a colossal disaster of a design decision when threads were added to Linux...

[mmstick]

Feel free to try out the scheduler branch

[techsy730]

Perhaps it can be a configurable? Whatever is better by default is the default behavior, but if you want to change that for an assignment, you can give some assignment mapping some parameters.

Sounds a little tricky to keep the ron file simple while keeping backwards compatibility then. And would it be possible to parse at runtime cleanly (since avoiding RTTI is much preferred)?

Perhaps a global setting may be better then