[LITMUS^RT] power management with litmus-rt

[Björn Brandenburg]

> On 15 Nov 2016, at 15:44, David Moncada <david_moncada at icloud.com> wrote:
> 
> 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?

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.

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, https://people.mpi-sws.org/~bbb/papers/pdf/rtss16b.pdf).

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?

- Björn