21–26 of 26 posts
Earlier quoted context omitted.
After all the patches are merged, will there be work on making PREEMPT_RT a boot-time or run-time choice rather than build-time? Why did you choose RT for your desktop?
I do audio stuff :)
(I'm deeply grateful for your contributions btw)
Will this eventually get merged into the main Linux branch? Are there any downsides to using the real time kernel for more mainstream tasks?
> Are there any downsides to using the real time kernel for more mainstream tasks? Real-time kernels tend to sacrifice anything in order to minimize latency, for being better for use cases where lowest latency is needed. This usually means tradeoffs regarding throughput, power consumption, resource usage, reliability and more, in order to get the lowest possible latency. In some cases you need really low latency, but…
Earlier quoted context omitted.
It's already being merged; PREEMPT_RT got merged last year. We're close to the endgame on that front. There are some performance tradeoffs to using an RT kernel; you trade some throughput for determinism. That said, I've been running RT on my desktop most of the time for years and never had any issues.
After all the patches are merged, will there be work on making PREEMPT_RT a boot-time or run-time choice rather than build-time? Why did you choose RT for your desktop?
Given the performance critical nature of how this changes things I personally think it's unlikely. It does stuff like change the way spinlocks work in the Kernel which would be not only difficult, but expensive without recompilation. The best I think you'll get is a boot-time option to switch between pre-compiled kernels.
That being said, most of the RT Linux patches over the years are actually compiled in all the time anyway so a lot of these improvements have been incorporated for a long time.
Will this eventually get merged into the main Linux branch? Are there any downsides to using the real time kernel for more mainstream tasks?
> Are there any downsides to using the real time kernel for more mainstream tasks? Real-time kernels tend to sacrifice anything in order to minimize latency, for being better for use cases where lowest latency is needed. This usually means tradeoffs regarding throughput, power consumption, resource usage, reliability and more, in order to get the lowest possible latency. In some cases you need really low latency, but…
I believe most of PREEMPT_RT has already been merged over the years. The expensive bits are all guarded behind a compile time flag.
Earlier quoted context omitted.
> Are there any downsides to using the real time kernel for more mainstream tasks? Real-time kernels tend to sacrifice anything in order to minimize latency, for being better for use cases where lowest latency is needed. This usually means tradeoffs regarding throughput, power consumption, resource usage, reliability and more, in order to get the lowest possible latency. In some cases you need really low latency, but…
Slight nit, real time systems are designed for a maximum worst case latency within some spec, not minimum latency. You can make a system that has a lower best case latency but that doesn't matter if the worst case causes a missed deadline. And in the context of real time systems, a missed deadline is either equivalent to a catastrophic error (hard real time) or really terrible but non catastrophic error (soft real ti…
I think you're conflating soft/hard real time with criticality (although they're often aligned)
Hard real time refers to a total system failure, even if it has trivial consequences. For example if a printer has a timing error at any point the page it's printing is irrecoverably ruined. It's hard real-time but low criticality.
Soft real time is where you can miss deadlines but the performance / experience degrades rather than fails. e.g. frame rate drops in a video game. The frames are still valid when delivered late, but the experience is poor.
> Slight nit, real time systems are designed for a maximum worst case latency within some spec, not minimum latency.
Indeed, in fact at times you don't even want a substantially lower minimum latency because it may cause unreasonable jitter in your output.
Earlier quoted context omitted.
After all the patches are merged, will there be work on making PREEMPT_RT a boot-time or run-time choice rather than build-time? Why did you choose RT for your desktop?
> will there be work on making PREEMPT_RT a boot-time or run-time choice rather than build-time? Given the performance critical nature of how this changes things I personally think it's unlikely. It does stuff like change the way spinlocks work in the Kernel which would be not only difficult, but expensive without recompilation. The best I think you'll get is a boot-time option to switch between pre-compiled kernels.…
However, while it can practically eliminate code overhead, it can't eliminate data overhead. I'm guessing the RT stuff does add overhead to data structures, and alternatives wouldn't fix that.