<div dir="ltr"><div class="gmail_default" style="font-size:small">Hi,</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I'm Meng Xu, a PhD student from the PRECISE lab at the University of Pennsylvania.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">We are measuring the scheduling overhead (SCHED and SCHED2 event) with the feather trace tool in LITMUS. When we randomly generate 450 tasks (rtspin) as a taskset and release them with arbitrary offset, we found that the worst-case scheduling overhead of GSN-EDF plugin is less than 40us.</div><div class="gmail_default" style="font-size:small">The hardware we use is Freescale IMX6 ARM board, which has 4 cores. </div><div class="gmail_default" style="font-size:small">(We did generate multiple such tasksets and vary the number of tasks from 50 to 450 as Dr. Brandenburg did in his RTSS09 paper[1], the scheduling overhead is from 12us to 20us when task number increases from 50 to 450.)</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default">However, the data in Dr. Brandenburg's RTSS09 paper [1] shows that the worst-case scheduling overhead of GSN-EDF is at least 80us (Fig. 6 on page 13 of [1]) when task number is 450.</div><div class="gmail_default"><br></div><div class="gmail_default"><b>My general question is:</b></div><div class="gmail_default">Is the scheduling overhead we measured reasonable?</div><div class="gmail_default"><br></div><div class="gmail_default"><b>My specific question is:</b></div><div class="gmail_default">1) Do we have to release tasks at the same time to reproduce the similar overhead value for GSN-EDF in [1]?</div><div class="gmail_default">2) Is it possible that LITMUS^RT has made some improvement since RTSS09 paper. The improvement reduces the scheduling overhead and therefore the smaller overhead value we measured is reasonable?</div><div class="gmail_default">3) The platform we use only has 4 cores and therefore the lock contention among cores may be (much) smaller, compared to the experiment Dr.  Brandenburg did in 2009? (We are not quite sure how many cores are used in the RTSS09 paper's overhead experiment.) Is it possible that we may observe much smaller overhead value like 20us due to less lock contention?</div><div class="gmail_default">4) Do we have to use other RT tasks instead of rtspin to run the overhead measurement in order to reproduce the result in [1]?</div><div class="gmail_default"><br></div><div class="gmail_default">[1] <a href="https://www.mpi-sws.org/~bbb/papers/pdf/rtss09_long.pdf">https://www.mpi-sws.org/~bbb/papers/pdf/rtss09_long.pdf</a></div><div><br></div><div><div class="gmail_default" style="font-size:small">​Thank you very much for your time and help in this question!</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Best regards,</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Meng​</div></div><div class="gmail_signature"><br><br>-----------<br>Meng Xu<br>PhD Student in Computer and Information Science<br>University of Pennsylvania<br><a href="http://www.cis.upenn.edu/~mengxu/" target="_blank">http://www.cis.upenn.edu/~mengxu/</a></div>
</div>