Glenn,<div><br></div><div>Yeah, that's my thinking as well. Bjoern has been a strong advocate of looking at normalized lateness/tardiness, so I'm interested to hear his input.</div><div><br></div><div>It does seem to me that a task with a short relative deadline will suffer a lot from tardiness qualitatively even if it has a long period.</div>
<div><br></div><div>-Jeremy Erickson<br><br><div class="gmail_quote">On Mon, Aug 27, 2012 at 5:49 PM, Glenn Elliott <span dir="ltr"><<a href="mailto:gelliott@cs.unc.edu" target="_blank">gelliott@cs.unc.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Since lateness is a function of absolute deadline, I thought it would be goofy to normalize against period.<div>
<div class="h5"><div><br></div><div><br><div><div>On Aug 27, 2012, at 4:46 PM, Jeremy Erickson <<a href="mailto:jerickso@cs.unc.edu" target="_blank">jerickso@cs.unc.edu</a>> wrote:</div><br><blockquote type="cite">Slightly off-topic question raised by this discussion: is it better to normalize tardiness against period or relative deadline? (It makes a difference for the journalized version of my ECRTS paper.) My inclination is that relative deadline seems more useful.<div>
<br></div><div>-Jeremy Erickson<br><br><div class="gmail_quote">On Mon, Aug 27, 2012 at 3:58 PM, Glenn Elliott <span dir="ltr"><<a href="mailto:gelliott@cs.unc.edu" target="_blank">gelliott@cs.unc.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><br>
On Aug 24, 2012, at 4:33 AM, Björn Brandenburg <<a href="mailto:bbb@mpi-sws.org" target="_blank">bbb@mpi-sws.org</a>> wrote:<br>
<br>
><br>
> On Aug 21, 2012, at 12:10 AM, Glenn Elliott wrote:<br>
><br>
>> I've implemented an alternative to hash-based tie-breaks. This<br>
>> alternative implements Bjorn's suggestion to tie-break on tardiness.<br>
>> Jobs that were tardy in their last invocation get priority. That is,<br>
>> the tardier a task's prior job was, the greater priority it gets in<br>
>> tie breaking.<br>
><br>
> Hi Glenn,<br>
><br>
> thanks a lot for spearheading this!<br>
><br>
>><br>
>> Some things to note:<br>
>> 1) Lateness is not normalized against relative deadline, so I believe<br>
>> some biases may emerge for some task sets. For example, suppose we<br>
>> have a implicit-deadline periodic task set where all tasks have equal<br>
>> periods, but execution times vary from task to task. I believe in the<br>
>> long term, tasks with longer execution times will be favored in<br>
>> tie-breaks (they will have greater lateness values, on average, even<br>
>> if they consistently win tie-breaks). At first I thought this was a<br>
>> problem, but now I think this may actually be a desirable property.<br>
><br>
> Not sure about this. Suppose you have a task with relative deadline 10ms and one with relative deadline 1000ms. Wouldn't a lateness of, say, 300ms be much more severe for the former task than for the latter? Shouldn't it receive priority based on that observation?<br>
><br>
>> 2) Lateness is computed in prepare_for_next_period(). While our use<br>
>> of lateness in this patch is limited to EDF scheduling, I thought this<br>
>> information might be useful in future plugins. It could also be<br>
>> exposed to the user space. I'm not sure if this is really of any<br>
>> value though.<br>
><br>
> Seems reasonable. Lateness could be exported via the control page.<br>
><br>
>> 3) The computation of lateness casts (unsigned long long)'s to (long<br>
>> long)'s before computing a difference. I originally had slightly more<br>
>> complicated code that avoided casts, but then I realized that our<br>
>> deadline comparators, i.e., lt_after(), do this casting as well. If<br>
>> we're not concerned about overflow there, I figured I shouldn't worry<br>
>> about it either. (Although, it does make me wonder why lt_t is<br>
>> (unsigned long long) and not (long long).)<br>
><br>
> The LITMUS^RT time types mirror Linux's time definitions. We use 64-bit unsigned integers because that is what Linux uses (or used when LITMUS^RT was started). The lt_after() / lt_before() comparison functions can handle overflows to some extent.<br>
><br>
>> 4) The idea of changing EDF tie breaking was generally well-received,<br>
>> so tie breaking methods is no longer a compile-time option. I can add<br>
>> it back in if others object.<br>
><br>
> I'd prefer a compile-time option (even if for no other reason than to enable easy comparisons).<br>
><br>
>> 5) As per our earlier discussions, I've also recoded the EDF logic to<br>
>> be more readable in a separate patch.<br>
>><br>
>> Two patches are attached. Patch #1 makes EDF logic more readable.<br>
>> Patch #2 implements lateness-based tie-breaks. (Patch #2 depends upon<br>
>> Patch #1.) These patches may be viewed on <a href="http://rtsrv.cs.unc.edu/" target="_blank">rtsrv.cs.unc.edu</a> for UNC<br>
>> folks (branch: wip-edf-tie-break). Note: I do not believe these<br>
>> patches include Bjorn's recent emergency fixes for partitioned<br>
>> scheduling.<br>
><br>
> Would it be possible to move to the Github repo that Chris set up for for-review branches? Then everyone could participate (and we get a pretty interface for free).<br>
><br>
> Thanks,<br>
> Björn<br>
><br>
> PS: I'll be without email access for the next week or so, so I'll be slow to respond to follow ups.<br>
><br>
><br>
> _______________________________________________<br>
> litmus-dev mailing list<br>
> <a href="mailto:litmus-dev@lists.litmus-rt.org" target="_blank">litmus-dev@lists.litmus-rt.org</a><br>
> <a href="https://lists.litmus-rt.org/listinfo/litmus-dev" target="_blank">https://lists.litmus-rt.org/listinfo/litmus-dev</a><br>
<br>
<br>
<br>
</div></div>Hello All,<br>
<br>
I've created a more robust patch for EDF tie-breaking. You may view the patch on github (wip-robust-tie-break):<br>
<a href="https://github.com/LITMUS-RT/litmus-rt/compare/wip-robust-tie-break" target="_blank">https://github.com/LITMUS-RT/litmus-rt/compare/wip-robust-tie-break</a><br>
<br>
What's new:<br>
1) Tie-break method is configurable at compile-time.<br>
2) Tie-break options: (1) Lateness, (2) Normalized Lateness (lateness is normalized by relative deadline), (3) Hash-based, (4) Traditional PID tie-break.<br>
3) fpmath.h. Normalized lateness required the introduction of fixed-point math. I had considered an algebraically equivalent method* to compare normalized lateness values, but I realized that overflow was easily possible if both lateness and relative deadline were on the order of ~4 seconds on 64-bit platforms (and 65 microseconds on 32-bit platforms). fpmath.h is originally from an earlier version of Litmus (pre-Björn re-arch, I think). I am not sure if it was ever mainlined into Litmus, or if it was only in a side-branch of Aaron Block's. I have been maintaining my own fpmath.h for the last two years. I have found it to be useful for implementing feedback control mechanisms for adaptive algorithms (Aaron used it for the same purposes). My version of fpmath.h is pretty much like Aaron's, except I add support for 64-bit systems. I think I also tweaked some #defines to allow use in liblitmus. If we don't want to use fpmath.h, I suppose we could scale lateness and relative deadline parameters before making a comparison. I wasn't sure what a proper scaling factor would be though. There is also some loss of precision, but there already is some loss with fpmath.h.<br>
<br>
I'm afraid that I need to start working on more core activities, so I would like to wrap up this tie-break patch soon. I would like us to decide exactly on what should go in staging (if anything). If there isn't any interest, I'll just maintain this on my own on the side. Please note that implementing different tie-breaking methods is pretty easy on top of the code I provide. It just takes a few lines of code in edf_common.c and an update to Kconfig to add the new method.<br>
<br>
* The comparison "L_1/D_1 > L_2/D_2" is equivalent to "L_1*D_2 > L_2*D_1"<br>
<br>
Thanks,<br>
Glenn<br>
<div><div><br>
<br>
_______________________________________________<br>
litmus-dev mailing list<br>
<a href="mailto:litmus-dev@lists.litmus-rt.org" target="_blank">litmus-dev@lists.litmus-rt.org</a><br>
<a href="https://lists.litmus-rt.org/listinfo/litmus-dev" target="_blank">https://lists.litmus-rt.org/listinfo/litmus-dev</a><br>
</div></div></blockquote></div><br></div>
_______________________________________________<br>litmus-dev mailing list<br><a href="mailto:litmus-dev@lists.litmus-rt.org" target="_blank">litmus-dev@lists.litmus-rt.org</a><br><a href="https://lists.litmus-rt.org/listinfo/litmus-dev" target="_blank">https://lists.litmus-rt.org/listinfo/litmus-dev</a><br>
</blockquote></div><br></div></div></div></div><br>_______________________________________________<br>
litmus-dev mailing list<br>
<a href="mailto:litmus-dev@lists.litmus-rt.org">litmus-dev@lists.litmus-rt.org</a><br>
<a href="https://lists.litmus-rt.org/listinfo/litmus-dev" target="_blank">https://lists.litmus-rt.org/listinfo/litmus-dev</a><br>
<br></blockquote></div><br></div>