<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Feb 5, 2014, at 3:03 AM, Björn Brandenburg <<a href="mailto:bbb@mpi-sws.org">bbb@mpi-sws.org</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br>On 17 Jan 2014, at 09:02, Björn Brandenburg <<a href="mailto:bbb@mpi-sws.org">bbb@mpi-sws.org</a>> wrote:<br><br><blockquote type="cite">On 17 Jan 2014, at 03:09, Glenn Elliott <<a href="mailto:gelliott@cs.unc.edu">gelliott@cs.unc.edu</a>> wrote:<br><br><blockquote type="cite">Why do we unlink() even if the scheduled task (entry->scheduled) will remain running? I have tasks that, upon exiting a non-preemptive section, are descheduled and are never rescheduled. I think they fell off a queue some where.<br></blockquote><br>A task that is unlinked should be put back into the ready queue (assuming it is still runnable). Since preempt=1 in your example, the scheduled task is no longer linked and hence should already be in the ready queue. But it is then removed from the ready queue because of the call to unlink() from schedule.<br><br>Calling unlinked on entry->scheduled again seems wrong, at least in this case. It still seems appropriate for the sleep=1 and out_of_time=1 cases. I'm surprised this didn't cause problems before. I guess you actually need a lot of non-preemptable sections within a certain length range to hit this case reliably. If the NP task is relinked before the core schedules or if the core never schedules, it won't cause a problem.<br><br><blockquote type="cite">Do we need to call job_arrival() on the job exiting the non-preemption section?<br></blockquote><br>No, I think that would be the wrong workaround. Not calling unlink() should do the trick.<br><br>Could you please add a simple test case for this to the liblitmus test suite? I'd like to reproduce this locally.<br></blockquote><br>Hi Glenn,<br><br>has this been resolved? If not, I would still appreciate a test case so that I can investigate the problem here as well.<br><br>Thanks,<br>Björn<br></div></blockquote></div><br><div>Hi Björn,</div><div><br></div><div>We haven’t found a fix for it yet. Do you mind if the test case uses Jonathan’s experiment-scripts? If not, use gen_exps.py to create a large high-utilization task set and schedule it under G-EDF. Run it with run_exps.py (it will launch lots of rtspin tasks) and wait for a few hours. Once I get in the office, I’ll send you some exact commands so we can be on the same page.</div><div><br></div><div>-Glenn</div></body></html>