Comment by zaptheimpaler

Comment by zaptheimpaler a day ago

Wow that sounds like a hell of an achievement. Here is the commit to the print_k function they mentioned as the final hurdle [1]. I have no idea what it does but maybe someone else here does. I wonder if the RT stuff will remain behind a config flag or become the default eventually. Is there any reason to not just have RT on by default?

I remember I had some nasty sound distortion issues on a Windows VFIO VM and it came down to events/interrupts not being handled quickly enough. I wonder what happens with an RT kernel and the VM thread having high priority in that situation.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

viraptor a day ago

> Is there any reason to not just have RT on by default?

It's a latency vs throughput trade-off usually. Ideally you'd want both to improve, but the more you switch between the processes, the more time you waste on busywork and cache invalidation rather than what the processes want to achieve. For example if RT wants to guarantee that your audio is more in sync, you're going to switch from your app to the audio system more often.

Reply View 2 replies

cwillu a day ago

That's a bit of a red-herring though, as the audio system will only preempt other processes if it's configured for very small buffers and given real-time permissions. A server's audio subsystem won't preempt actual work because a server won't _have_ an audio subsystem running, let alone be configured for sub-millisecond latency.
The real trade-off is the overhead required to make all kernel operations potentially safe WRT maximum wait times.

Reply View | 1 reply
- viraptor a day ago
  
  This is a qualified example. Yes, if you're not doing audio, audio is not going to interrupt. But that's a moot point...
  
  Reply View | 0 replies