[LITMUS^RT] Remove dependence on scheduler_tick() (WAS: 2014.2 release candidate)
Björn Brandenburg
bbb at mpi-sws.org
Tue Jun 3 21:35:51 CEST 2014
On 03 Jun 2014, at 20:27, Glenn Elliott <gelliott at cs.unc.edu> wrote:
> Does this mean we can take advantage of Linux kernel features that disable ticks (CONFIG_NO_HZ and others)?
Yes, indeed. We no longer conflict with these options.
> Also, how does this patch change the meaning of quantum budget enforcement with respect to event-driven plugins?
Not sure we ever had a particularly well defined meaning. De facto it was triggered when a real-time task was hit by a scheduler tick. This is still the case. Of course, if you turn on CONFIG_NO_HZ_FULL, you may not get scheduler ticks for quite a while, until there are at least two ready jobs on your core.
> 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?
I think the patch doesn’t significantly change the user-visible behavior. It’s as functional as before.
> Is there a difference between PFAIR’s notion of quantum budget enforcement and that of the other plugins?
For PFAIR, quantum-based enforcement happens to be precise, for the others it is not. Other than that, there’s no difference.
I’m not really sure if there’s much value left in the quantum-based budget enforcement. It’s not precise enough to be analytically useful, and the precise enforcement is cheap enough that there’s no reason not to use it. I think it’s more of a legacy feature left over from the times when we didn’t have any precise enforcement. There’s no pressing reason to get rid of it, but it’s not terribly useful anymore either, at least in my view.
Thanks,
Björn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20140603/afcb167c/attachment.html>
More information about the litmus-dev
mailing list