[LITMUS^RT] Interrupt latencies effects

[Youcef Amine Benabbas]

Hi Glenn,

Thank you very much for your clarifications.

--
Youcef

On Mon, 2012-10-08 at 16:29 -0400, Glenn Elliott wrote:
> Hi Youcef,
> 
> Regular Litmus does not change Linux's interrupt handling methods.  Thus, after every top-half, up to 10 bottom-halves (pending softirqs) may be executed before the CPU exits the interrupt context.  However, Litmus has been ported to Linux 3.x, so the "threadirqs" kernel boot parameter can be used to ensure more bottom-halves are always threaded.  Beware that by using this parameter it is possible for Litmus threads to starve out bottom-half processing since Litmus threads always have higher priority than SCHED_FIFO, _RR, _OTHER, etc..  I don't believe there has been much testing done with Litmus and Linux's threadirqs, but I see no reason why it should not work.
> 
> I have done some work to introduce threaded interrupt handling into Litmus (klmirqd & PAI: http://www.cs.unc.edu/~anderson/papers/ecrts12b_long.pdf)-- this is not a part of our mainline Litmus though (slightly out-of-date patch: https://wiki.litmus-rt.org/litmus/Publications?action=AttachFile&do=view&target=gpu-klmirqd-litmus-rt-ecrts12.patch).  However, these techniques require that a bottom-half can be mapped to a real-time thread "owner."  For example, suppose a real-time thread blocks on disk I/O.  Interrupts from the disk while the real-time thread is blocked should be scheduled with a priority at least that of that blocked thread.  You can get away from owners if you run the interrupt handling threads as if they were periodic servers.  It would not be difficult to modify klmirqd to do this.  You could then funnel all softirqs to klmirqd threads instead of ksoftirqd threads.  On the other hand, it may even be possible to run Linux's ksoftirqd threads as real-time thre!
 ad!
>  s directly.  Litmus has the capability of changing the scheduling class of another thread, so I see no reason why ksoftirqd threads could not be forced to be Litmus threads and given an execution budget.
> 
> Options:
> 1) Stick with stock Linux implementation.  Small risk of bottom-half starvation, but real-time threads are disrupted.
> 2) Use Linux + threadirqs boot parameter.  Greater risk of bottom-half starvation.
> 3) Use Litmus's klmirqd or PAI (not in mainline Litmus).  Requires the mapping of interrupt bottom-halves to owners.
> 4) Use Litmus's klmirqd and configured as servers.
> 5) Force Linux's threadirqs to become Litmus tasks.  This could be done in plug-in activation.
> 
> If you need something that works "well enough," I would take a look at options 1 and 5.  If you need something that performs really well and has better predictable behavior, go with PAI.  If you can sacrifice throughput for better predictable behavior, go with klmirqd.
> 
> -Glenn
> 
> 
> On Oct 8, 2012, at 3:52 PM, Youcef Amine Benabbas <s9yobena at stud.uni-saarland.de> wrote:
> 
> > How does litmus guarantee that handling of interrputs (which under
> > linux, results in the preemption of any high priority process) will not
> > result in deadline misses of real time task.
> > 
> > Does it assume that interrupt handlers execute for only short durations
> > and that most work is done by softirqs and tasklets.
> > 
> > Thanks,
> > Youcef
> > 
> > 
> > _______________________________________________
> > litmus-dev mailing list
> > litmus-dev at lists.litmus-rt.org
> > https://lists.litmus-rt.org/listinfo/litmus-dev
> 
> 
> _______________________________________________
> litmus-dev mailing list
> litmus-dev at lists.litmus-rt.org
> https://lists.litmus-rt.org/listinfo/litmus-dev