[LITMUS^RT] Improving Latency

[Glenn Elliott]

I've recently started chatting with a gentleman who builds real-time systems for pro-audio work, and he had some interesting things to say.  I thought I would share them here.

He was curious how Litmus differed from PREEMPT_RT.  He seemed quite interested in our global/clustered- deadline schedulers, etc.  However, the fact that we aren't based on PREEMPT_RT was disappointing to him (I had to remind him that we are only a research platform).  Still, he mentioned that he had to abandon PREEMPT_RT for a time while it was stuck on 2.6.33-rt.  This was his alternative:

"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.

The 'threadirqs' boot parameter new to 2.6.39 was also mentioned in our discussions.  I said that we haven't explored it yet, but that there are integration concerns of Litmus tasks starving IRQ handlers.

-Glenn