[LITMUS^RT] new patches and new branch

Björn Brandenburg bbb at mpi-sws.org
Wed Jun 26 16:08:30 CEST 2013


On Jun 25, 2013, at 4:52 PM, Glenn Elliott <gelliott at cs.unc.edu> wrote:

> I was looking at timer slack in select() yesterday---I'm glad to find that someone has already done the necessary critical thinking and work!

NB: only the do_nanosleep() patch is actually well-tested. The rest of the changes are analogous, but we haven't benchmarked them.

> 
> Questions about the GSN-EDF link changes: Do you have any empirical data on how this changes average case preemption/migration costs in comparison to the affinity-aware linking? Does it make sense to avoid an IPI if it means migrating across a CPU socket?  It seems we should be chasing after improved average-case behavior here because I don't believe this latest patch changes schedulability analysis formulas---just possibly the values we plug in.

The "local CPU first" shortcut serves to reduce scheduling latency in the average case (unless the system is highly utilized), and also affects observed maxima in the case of having one task per core. The latter is the workload run by cyclictest, which we used to compare scheduling latency across LITMUS^RT, Linux, and PREEMPT_RT.

	https://www.mpi-sws.org/~bbb/papers/pdf/ospert13.pdf

The affinity-aware linking doesn't help to improve scheduling latency. Conversely, I don't think the "local CPU first" shortcut significantly affects preemption / migration costs. In any case, we could make it optional with a CONFIG option.

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

Thanks,
Björn





More information about the litmus-dev mailing list