[LITMUS^RT] Alternative to deferring work

Björn Brandenburg bbb at mpi-sws.org
Thu Oct 26 10:27:14 CEST 2017


> On 23. Oct 2017, at 23:38, Gabriel Lozano <gabrilozano90 at gmail.com> wrote:
> 
> Hello all, I'm Gabriel and I've been working with litmus-rt in the past few weeks trying to implement a prototype scheduler that features predictable processor frequency scaling for a project. I've been having some problems so I thought I might as well ask here for some guidance from someone more experienced...
> 
> The scheduler is somewhat straightforward: it is based on P-EDF, all it has to do is to initiate a frequency scaling step at certain points in the schedule, specifically during task release and completion. However, the scaling step needs to be done out of interrupt context (with iqrs on). Since both releases and completions are handled when irqs are saved, I need to perform this task somewhere else.
> 
> An idea I had is to implement a top half/bottom half solution: raise a soft irq inside the handlers for release and completion and defer the scaling step. The problem is I'm not sure if there's any guarantee that the scaling will be performed as soon as the irqs are back on. Another thing that I though about was to use a message passing protocol and having a DSP perform all frequency adjustments out of interrupt context. However, I have the feeling this be overkill for this problem.
> 
> I'd like to have frequency scaling done right after releases/completions. But I feel these solutions are overly complicated and so I was wondering if someone in the community had already done something alike using a simpler solution...

Dear Gabriel,

unfortunately LITMUS^RT does not provide a ready-made “do work after dropping the scheduler locks” mechanism. I implemented similar functionality some years ago in one-off project branches, but this never made it back into the mainline tree. 

If you come up with a nice, generic, and clean solution, please consider submitting it for merging. 

Thanks,
Björn




More information about the litmus-dev mailing list