[LITMUS^RT] Improving Latency

[Mac Mollison]

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

Just a reminder that my userspace scheduling library [1] supports C-EDF
atop PREEMPT_RT. Glenn, you might consider mentioning this option to
the person you met who works with audio systems.

Since this is a relatively new thing, he would probably run into major
problems with it. But it would be valuable for my research to find out
about any problems or limitations I'm not already aware of and see if
they can be addressed.

[1] http://cs.unc.edu/~mollison/pubs/rtcsa12.pdf

-Mac


On Wed, 6 Jun 2012 09:35:51 -0700
Glenn Elliott <gelliott at cs.unc.edu> wrote:

> 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
> _______________________________________________
> litmus-dev mailing list
> litmus-dev at lists.litmus-rt.org
> https://lists.litmus-rt.org/listinfo/litmus-dev