realtime: request SCHED_RR using CAP_SYS_NICE

[Emantor]

Try to gain SCHED_RR (round-robin) realtime scheduling privileges before
starting the server. This requires CAP_SYS_NICE on Linux systems.
We additionally register a pthread_atfork callback which resets the
scheduling class back to SCHED_OTHER (the Linux system default).

Due to CAP_SYS_NICE, setting RLIMIT_RTPRIO has no effect on the process
as documented within man 7 sched (from Linux):

  Privileged (CAP_SYS_NICE) threads ignore the RLIMIT_RTPRIO limit;
  as with older kernels, they can make arbitrary changes to
  scheduling policy and priority. See getrlimit(2) for further
  information on RLIMIT_RTPRIO

Note that this requires the sway distribution packagers to set the
CAP_SYS_NICE capability on the sway binary.

Supersedes #6992

[kennylevinsen]

Hmm. So on FreeBSD, this requires PRIV_SCHED_SET.

From what I can tell that is primarily given to root, but from reading the code it seems like mac(9) can interfere with these decisions. Maybe it can be used to grant the privilege? Might need a FreeBSD expert to comment...

[Emantor]

Apparently this can be done using mac(9), but requires it's own kernel module (code).

[kennylevinsen]

... oh. rtkit isn't a thing on FreeBSD either from what I can tell, so maybe this is just not something people do over there. We fail gracefully here anyhow.

(As an aside, I recently noticed that rtkit advices one to try sched_setscheduler before rtkit, so we need the manual sched_setscheduler code anyhow.)

[kennylevinsen]

Hmm, so pipewire ends up having priority 9, but sched_get_priority_min(SCHED_RR) is -2 so we're below pipewire which is a little annoying. I wonder where the pipewire's priority comes from - rtkit seems to ask for priority 0?

[Emantor]

Pipewire uses the MaxRealtimePriorityproperty from RTKit to request the highest possible priority from RTKit. This sounds fine and also sway requesting the lowest sounds good. According to man 2 sched_get_priority_min:

Processes with numerically higher priority values are scheduled before processes with numerically lower priority values.
Thus, the value returned by sched_get_priority_max() will be greater than the value returned by sched_get_priority_min().

So pipewire should be scheduled before sway.

[kennylevinsen]

Pipewire uses the MaxRealtimePriority property from RTKit to request the highest possible priority from RTKit.

Oh, I just realized that I was checking prio, not rtprio. That explains why I was seeing weird numbers. D'oh.

So pipewire should be scheduled before sway.

Yeah, my thought was that it makes sense that we as the graphical window system would have either same or higher priority than audio and screen capture routing. It does seem a bit aggressive from pipewire's perspective to ask for the highest priority, outranking even a bunch of kernel threads...

(This is of course nowhere near as important as just being SCHED_RR in the first place - even if our priority is wrong, we're competing with a much smaller group of processes.)

[kennylevinsen]

Other than being unsure about the priority we should use, LGTM.

[Emantor]

IMO, starting with the minimum priority is fine. We can still adjust this or expose this as a user configurable option later.

[kennylevinsen]

Thanks!