3 ms·

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 bu

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/linux.git/commit/?id=c903327d3295b135eb8c81ebe0b68c1837718eb8 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

viraptor 2y 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.
- cwillu 2y 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.
  - viraptor 2y 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...

viraptor 2y 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.

cwillu 2y 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.
- viraptor 2y 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...