[LITMUS^RT] Improving Latency

[Björn Brandenburg]

On Jun 6, 2012, at 6:35 PM, Glenn Elliott wrote:

> "A year or so ago, when rt was stuck at 2.6.33-rt i couldn't use it (too old), and thus had to improvise a system that could handle lower latencies. I ended up settling on 'Zen-kernel' - which is an optimized kernel for desktop usage ( that has BFS scheduler / BFQ io scheduler ). With some tweaking (of both BFS and BFQ) and using the SCHED_ISO policy (on Xorg and jackdbus), i was able to get fairly lower latencies and reliable performance (using kernel 2.6.37), somewhere around 2ms... In fact, it was more reliable than using CFS or any other scheduler, with the same kernel (however, current RT is better)."
> 
> I don't believe latency has been a direct priority in Litmus (I don't know if anyone has even made the standard measurements). Although, I recall Björn stating that we weren't doing so well in comparison to PREEMPT_RT.  Is BFS/BFQ something we should explore for Litmus?  If I recall correctly, BFS has issues with scalability (best for < 4 (or 8?) CPUs), but perhaps this wouldn't be a big deal for us since it would really only handle background work.  We just need to reduce interference on real-time tasks.

Interesting anecdote, thanks for sharing it. BFS is a global scheduler, so I think our G-EDF support is no worse and actually a better fit for soft real-time apps.

The main reason why we *should* be based on PREEMPT_RT is that normal Linux suffers from prolonged times in which interrupts are disabled. This hurts the maximum event latency under partitioned schedulers in LITMUS^RT (I've seen this on Ludwig if there's a heavy network or disk I/O load, using tempfs likely helps to mask this issue).

BFS does not affect this, so switching to it  would not help LITMUS^RT. I believe the anecdote says more about CFS and Linux's CFS load-balancer (not very predictable, to say the least) than about Linux's IRQ latencies. In fact, even the current version of LITMUS^RT should offer much better IRQ latencies than 2ms (though I'm not sure exactly which latencies the audio engineer is referring to, presumably there's some userspace processing involved).

- Björn