<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Thanks for the reference to your paper, I'll look into it. I can see you've attained almost optimal performance in the HRT case, so it's worthy to explore the semi-partitioned approach with energy constraints in mind.<div class=""><br class=""></div><div class="">I haven't thought it through, but I think for a first stage I'll be using synthetic workloads composed of periodic/sporadic tasks. I'm also interested in comparing the performance of different (contrasting) energy-aware sched. techniques, i.e. DVFS vs. sleep states/race-to-idle. Hence my previous question, and my concern for knowing beforehand if LITMUS-RT fulfills my needs.</div><div class=""><br class=""></div><div class="">Thanks again for your quick response. Regards!<br class=""><div class=""><br class=""><div class=""><div><blockquote type="cite" class=""><div class="">On Nov 15, 2016, at 9:01 AM, Björn Brandenburg <<a href="mailto:bbb@mpi-sws.org" class="">bbb@mpi-sws.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><blockquote type="cite" class="">On 15 Nov 2016, at 15:44, David Moncada <<a href="mailto:david_moncada@icloud.com" class="">david_moncada@icloud.com</a>> wrote:<br class=""><br class="">A have a few more doubts concerning power management. I'd like a platform for implementing and comparing the performance of a few energy-aware sched. algs., determining (or rather confirming) which approach fits best a particular scenario. I've read Linux might be a source of unpredictable overheads, so this would have to be accounted for. From an implementation point of view, do you think partitioned/global approaches mix well with racing-to-idle strategies, or could it somehow "break" the work-conserving properties of global scheduling, making the approach practically inconvenient or unmanageable?<br class=""></blockquote><br class="">Good questions; I think there are no definitive answers (yet). Generally, global scheduling should mesh well with race-to-idle, since the implicit load-balancing ensures that all cores reach idleness as quickly as possible. Partitioned scheduling could at least theoretically be at a disadvantage here.<br class=""><br class="">However, in practice, global scheduling comes with (substantially) higher overheads. Also, in terms of schedulability, partitioned scheduling does quite well in terms of hard real-time schedulability. And semi-partitioned scheduling does even better (I have an upcoming RTSS’16 paper on this, <a href="https://people.mpi-sws.org/~bbb/papers/pdf/rtss16b.pdf" class="">https://people.mpi-sws.org/~bbb/papers/pdf/rtss16b.pdf</a>).<br class=""><br class="">So (semi-)partitioned scheduling might still come out ahead, even when taking into account power- and energy-management. Whether or not this is the case depends on your platform (can one core clock down when another core on the same package is still running at full throttle?), your workload (does it respond well to DVS?), and how you define ‘success’. Are you primarily interested in provable guarantees for simple periodic or sporadic workloads, or are you going after observed performance for real-world code?<br class=""><br class="">- Björn<br class=""><br class=""><br class="">_______________________________________________<br class="">litmus-dev mailing list<br class=""><a href="mailto:litmus-dev@lists.litmus-rt.org" class="">litmus-dev@lists.litmus-rt.org</a><br class="">https://lists.litmus-rt.org/listinfo/litmus-dev<br class=""></div></div></blockquote></div><br class=""></div></div></div></body></html>