[LITMUS^RT] new patches and new branch

[Björn Brandenburg]

On Jun 26, 2013, at 5:43 PM, Glenn Elliott <gelliott at cs.unc.edu> wrote:
> 
> On Jun 26, 2013, at 7:08 AM, Björn Brandenburg <bbb at mpi-sws.org> wrote:
> 
>> On Jun 25, 2013, at 4:52 PM, Glenn Elliott <gelliott at cs.unc.edu> wrote:
>> 
>>>  did you test Litmus with "threadirqs" set in the kernel boot parameters?  Litmus tasks blocked for an I/O interrupt could suffer an unbounded priority inversion though...

We ran the kernel "as is", without specifying additional options. threadirqs would probably have reduced the outliers considerably, but not as much as PREEMPT_RT.

> With respect to the "local CPU first" shortcut, do you suppose we're looking at an application-dependent trade-off?  We can either reduce a small fixed cost (scheduling latency), or reduce occasional big costs (migration of tasks with large WSS).  Suppose that we have two available CPUs when we need to schedule task T: (1) a local CPU and (2) a remote CPU with which T has affinity.  Suppose (1) is an arbitrary distance X, w.r.t memory hierarchy, from (2).  If we wish to minimize task/job response time, then I would expect the following:
> 
> 1) For a task with a small WSS, it is best to schedule on the local CPU.
> 2) For a task with a large WSS, it is best to schedule on the remote CPU.
> 3) For a task with a  medium WSS, the best CPU is dependent upon X.
> 
> Hardware-specific and application-specific characteristics would define what small/medium/large mean.

Yes, think this is right in principle. 

> I guess what I'm trying to say is that I see no way for Litmus to offer a good one-size-fits-all solution offline, so I agree that a compile-time option is best.  Although, it would be interesting if Litmus could go through some sort of "self-tuning" phase at boot.  Applications could then inform Litmus of their WSS.  Litmus could run through the three scenarios above to make better scheduling decisions.  Still, I wonder if there would be any real payoff to all this.  Perhaps it would just add a lot of complexity to occasionally save a few microseconds.

I don't think this would be worth the complexity. It probably makes sense to have an option to disable behavior that is undesirable for specific workloads, though.

> 
>>> Also, going forward, how do you feel about committing to keeping C-EDF in sync with GSN-EDF?  I'd be happy to port any patches from GSN-EDF to C-EDF since I appear to be its primary user.
>> 
>> Sure. They should generally be in sync.  In this case, we were using G-EDF and porting it to C-EDF just wasn't a priority yet. (Rebasing cleanly on top of 3.0 took a couple of days.)
> 
> Great! Glad to hear it.

For now, I'll continue to look into porting / rebasing the kernel.  I'd be happy to merge a patch that makes the shortcut optional and extend it to C-EDF.

Thanks,
Björn