[LITMUS^RT] Remove dependence on scheduler_tick() (WAS: 2014.2 release candidate)

[Glenn Elliott]

On Jun 3, 2014, at 2:13 PM, Björn Brandenburg <bbb at mpi-sws.org> wrote:

> Yet more significant changes, which I'd like to roll into the next release as well.
> 
> 	https://github.com/LITMUS-RT/litmus-rt/compare/next...prop%2Fremove-scheduler-ticks
> 
> Context: LITMUS^RT has traditionally used the Linux scheduler tick to implement quantum-driven scheduling. With Linux's move to dynticks (i.e., suppressing the scheduler tick whenever possible), this approach is becoming increasingly brittle and will be eventually untenable. Further, it forces us to hook into kernel/sched/core.c more aggressively than needed, which complicates porting.
> 
> The patch series linked above fixes this by 1) making PFAIR independent of the scheduler tick by using custom hrtimers to mark quantum boundaries instead, which allows us to 2) completely remove the scheduler_tick() integration from LITMUS^RT.
> 
> This changes nothing for event-driven plugins (all EDF plugins and P-FP), and makes the Pfair plugin slightly more sane. On top, we now can configure arbitrary quantum lengths (modulo limitations imposed by hardware overheads; there's currently a safety threshold of 500us).
> 
> Unless there are problems, I'll incorporate these changes into the next release.
> 
> Thanks,
> Björn


Neat!  Does this mean we can take advantage of Linux kernel features that disable ticks (CONFIG_NO_HZ and others)?

Also, how does this patch change the meaning of quantum budget enforcement with respect to event-driven plugins?  Is it still supported?  If not, should we throw an error if the user tries to use quantum budget enforcement or silently upgrade their request to precise budget enforcement?  Is there a difference between PFAIR’s notion of quantum budget enforcement and that of the other plugins?

-Glenn