[LITMUS^RT] power management with litmus-rt

[David Moncada]

Hello Björn, it's David again

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?

Thank you so much for your help. Regards!

> On Nov 7, 2016, at 10:42 AM, Björn Brandenburg <bbb at mpi-sws.org> wrote:
> 
> 
>> On 7 Nov 2016, at 17:32, David Moncada <david_moncada at icloud.com> wrote:
>> So, if I understand correctly, currently LITMUS-RT does not include any energy-aware scheduler
> 
> Correct.
> 
>> but, is it possible to extend the already existing schedulers in LITMUS-RT with DVFS and sleep states functionality? 
> 
> Yes, you could certainly do that. 
> 
>> Or rather one would need to develop energy-aware RT schedulers for LITMUS-RT from scratch?
> 
> Well, you’ll need to develop the energy-awareness, but you can reuse everything else. Like I said, for P-FP and PSN-EDF this shouldn’t be so hard, but the global cases may be more involved.
> 
>> About your comment on CPU hot-plugging, does it mean that LITMUS-RT won't work when turning processors off/on even if the architecture allows sleep states?
> 
> Yes. The issue is that we don’t handle hotplugging events and that we use for_each_cpu() instead of for_each_online_cpu() in various places. This could be fixed with a moderate amount of work, but somebody needs to volunteer to do it. 
> 
>> 
>> Thanks for clearing my doubts, I'm interested in both partitioned and global approaches, so extending the existing schedulers would save some work. Also, it would be nice to have an already tested platform to start working with.
> 
> Yes, I think LITMUS^RT is a reasonable starting point and certainly much easier than starting from scratch. That said, it’s still a nontrivial challenge, so I’d caution to budget a fair amount of time.
> 
> Best regards,
> Björn
> 
> 
> _______________________________________________
> litmus-dev mailing list
> litmus-dev at lists.litmus-rt.org
> https://lists.litmus-rt.org/listinfo/litmus-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20161115/6adc9b6a/attachment.html>