Hello everyone,<div><br></div><div>just recompiled the kernel with the modifications and the bug is fixed. Thank you Björn.</div><div><br></div><div>I have two more questions. The current version of LITMUS is equivalent of which version in the paper "On the implementation of Global Real-Time schedulers"? I suppose it is, FE1, with fine-grained ready queue, event-driven scheduling, and 1 cpu handling interrupts, Am I right?</div>
<div><br></div><div>I would like to measure also the overhead to send an IPI. Are the feather-trace SEND_RESCHED_START and SEND_RESCHED_END events used to measure IPI overhead?</div><div><br></div><div>Best regards,</div>
<div>Giovani<br><br><div class="gmail_quote">On Thu, May 31, 2012 at 4:46 AM, Björn Brandenburg <span dir="ltr"><<a href="mailto:bbb@mpi-sws.org" target="_blank">bbb@mpi-sws.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">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 remove the '&&<br>
> !preempt' before job_completion in the _schedule method, and<br>
> compensate by adding a check for is_queued(task) in the _requeue<br>
> method so that job_completion could be called after a preemption<br>
> without causing a BUG.<br>
><br>
>> It seems to me the right thing to do is to not add unlinked tasks to the ready queue if they have no budget remaining. Then it is safe to process the job completion even if it coincides with a preemption.<br>
><br>
> This is a better solution.<br>
<br>
<br>
</div>I have pushed a proposed fix to prop/budget-bug-fix. It seems 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>
</blockquote></div><br></div>