In a project I wrote, I’m having trouble with real-time tasks like audio. When the CPU gets busy, audio performance noticeably slows down.
Is there anything beyond just setting thread priorities that should be considered for proper scheduling? Also, could tweaking the setting help in this case? If the CPU quantum setting does matter, how do you usually determine an effective value, is it mostly empirical tuning?
That depends on the kernel you are using. Can you be more specific on kernel and hardware platform?
Note that, by default, there is no CPU load balancing, i.e. apart from priorities, the affinity assignment also has a significant impact on performance.
I’m working on x86 hardware with the hw kernel. I’ve also run into similar issues on NOVA, though I haven’t done a full investigation there yet.
I see. Has there been any specific mechanism or best practice for assigning CPU affinity or priorities? I’ve experimented with thread priorities and CPU quantum settings, but I didn’t notice much improvement in performance.
With the new kernel scheduler introduced by Genode 25.08, the CPU quantum is not effective anymore. Moreover, there are effectively only four priorities/groups. These four priorities provided by the new kernel scheduler correspond to the four latency classes of Sculpt OS: device driver, multimedia, default and background. Threads in the device-driver class shall be enabled to achieve the lowest latency whereas threads in the background class will experience higher latency. Your init-hierarchy should therefore use 4 priority levels in total where (logical) priority 0 would map to the device-driver class, -1 to multimedia, -2 to default and -3 to background. (Note that this is a bit more complex for Sculpt OS.)
You should first make sure that your intended affinity and priority assignment is effective (e.g. by using the top component to log the active threads). On hw, the device driver priority is 0 and the background priority is 3.
I would try to put your audio components on the same core and on the multimedia priority. Assign everything else to the other cores. If it turns out that there is a high CPU load on your “audio” core, you can distribute the audio components on multiple cores. Otherwise, if audio works fine, you can gradually add background and default priority components to the audio core.
Note that the hw scheduler uses a fixed (but not set in stone) set of scheduling parameters. You find a more detailed explanation in the scheduler.h. In the current setting device driver components get the largest share of the CPU core, i.e. whenever such a component is active on a CPU core (and consuming a significant CPU share), the multimedia components will only be able to maintain their low latency if their combined CPU share is below a certain threshold (23% to 33% depending on whether default and/or background components are active).