module-rt and module-rtkit forces main thread niceness to -11
- PipeWire version (
pipewire --version
): 0.3.43 - Distribution and distribution version (
PRETTY_NAME
from/etc/os-release
): Debian GNU/Linux bookworm/sid - Desktop Environment: KDE Wayland
- Kernel version (
uname -r
): 5.15.0-2-amd64
Description of Problem:
When an process uses PipeWire and loads the rtkit or rt module (e.g. from client-rt.conf or a modified client.conf), the main thread of the process has its niceness value changed to -11. This invariably alters the performance characteristics of the process both on the system as a whole (being given more CPU time over other running processes) and within itself (for multi-threaded apps, with the main thread taking more CPU time over other threads than it normally would).
How Reproducible:
Always.
Steps to Reproduce:
- Run an app that loads module-rt. An ALSA app using the pipewire device (which uses client-rt.conf) is an easy test.
- Run
ps -elT
in a separate terminal while that other app is running. - Observe the niceness value for that process's main thread changed to -11.
Actual Results:
The process's main thread niceness changed to -11.
Expected Results:
The process's main thread niceness is left alone.
Additional Info (as attachments):
This is something I notice happening with module-rtkit. I see that it was recently merged with module-rt, however looking at the code, the same logic is present. Specifically, pipewire__module_init
calls set_nice(impl, impl->nice_level);
, which for some reason changes the niceness of the calling thread, and presumably this is happening on the process's main thread:
https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/75212a40/src/modules/module-rt.c#L825
It should be noted that POSIX defines the niceness value as being per-process. Each process only has one niceness value for all threads with POSIX, and the setpriority
call is expecting a PID with PRIO_PROCESS
. Linux actually breaks POSIX compatibility here and has a niceness value per-thread, allowing that call to take a TID instead of a PID, but that's Linux-specific behavior and not necessarily portable to other POSIX systems (or the glibc wrapper function). The man pages also warn that Linux may be made standards conformant in the future (how likely this is to happen, I have no idea, but it's a warning they give).
-
pw-dump > pw-dump.log
: pw-dump.log