<br><br><div class="gmail_quote">2012/6/14 Youcef Amine Benabbas <span dir="ltr"><<a href="mailto:s9yobena@stud.uni-saarland.de" target="_blank">s9yobena@stud.uni-saarland.de</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Hi Giovani,<br>
<div class="im"><br>
On Thu, 2012-06-14 at 12:21 -0300, Giovani Gracioli wrote:<br>
> Hello everyone,<br>
><br>
><br>
> just recompiled the kernel with the modifications and the bug is<br>
> fixed. Thank you Björn.<br>
><br>
><br>
> I have two more questions. The current version of LITMUS is equivalent<br>
> of which version in the paper "On the implementation of Global<br>
> Real-Time schedulers"? I suppose it is, FE1, with fine-grained ready<br>
> queue, event-driven scheduling, and 1 cpu handling interrupts, Am I<br>
> right?<br>
><br>
><br>
> I would like to measure also the overhead to send an IPI. Are the<br>
> feather-trace SEND_RESCHED_START and SEND_RESCHED_END events used to<br>
> measure IPI overhead?<br>
<br>
</div>Yes, they are equivalent. I am working on measuring this overhead plus<br>
other overheads to implement overhead-aware schedulability tests.<br>
<br>
By the way, I am trying to get a TS_SEND_RESCHED_(START/END) for<br>
real-time tasks, i.e. timstamps with task_type==TSK_RT. Unfortunately I<br>
could not get such timestamps.<br>
<br>
I followed execution paths producing TS_SEND_RESCHED, but it seemed to<br>
me impossible to get them.<br>
<br>
I would appreciate your advice regarding measuring IPI latency for<br>
real-time tasks.<br></blockquote><div><br>Hi Youcef,<br><br>I had that problem before. According to Andrea and Björn, SEND_RESCHED overhead must be collected with the best-effort option in ft2csv (-b).<br>I think it's because of the way the measurement is implemented.<br>

<br>Thanks,<br>Felipe<br><br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Best regards,<br>
Youcef<br>
<div class="im HOEnZb"><br>
<br>
><br>
><br>
> Best regards,<br>
> Giovani<br>
><br>
> On Thu, May 31, 2012 at 4:46 AM, Björn Brandenburg <<a href="mailto:bbb@mpi-sws.org">bbb@mpi-sws.org</a>><br>
> wrote:<br>
>         On May 31, 2012, at 7:34 AM, Jonathan Herman wrote:<br>
><br>
>         > We encountered this same issue with the mixed-criticality<br>
>         > and EDF-HSB schedulers. Our poor implementation was to<br>
>         remove the '&&<br>
>         > !preempt' before job_completion in the _schedule method, and<br>
>         > compensate by adding a check for is_queued(task) in the<br>
>         _requeue<br>
>         > method so that job_completion could be called after a<br>
>         preemption<br>
>         > without causing a BUG.<br>
>         ><br>
>         >> It seems to me the right thing to do is to not add unlinked<br>
>         tasks to the ready queue if they have no budget remaining.<br>
>         Then it is safe to process the job completion even if it<br>
>         coincides with a preemption.<br>
>         ><br>
>         > This is a better solution.<br>
><br>
><br>
><br>
>         I have pushed a proposed fix to prop/budget-bug-fix. It seems<br>
>         to fix the issue for me. Everyone, please test & review.<br>
><br>
>         Giovani, can you please confirm that this fixes the bug?<br>
><br>
>         Thanks,<br>
>         Björn<br>
><br>
><br>
><br>
</div><div class="HOEnZb"><div class="h5">> _______________________________________________<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>
<br>
<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>
</div></div></blockquote></div><br>