Re: [Ksummit-discuss] Energy-aware Scheduling Workshop

[Preeti U Murthy <preeti@linux.vnet.ibm.com>]

Hi Amit, Lorenzo,

On 05/14/2014 04:07 PM, Lorenzo Pieralisi wrote:
> Hi Preeti,
> 
> On Wed, May 14, 2014 at 11:01:08AM +0100, Preeti U Murthy wrote:
>> Hi Morten,
>>
>> Thank you for initiating this.
>>
>> On 05/12/2014 09:02 PM, Morten Rasmussen wrote:
>>> Hi,
>>>
>>> Last year's Energy-Aware Scheduling workshop [1,2] was a good
>>> opportunity for interested parties to discuss some of the open issues in
>>> this area face to face. While work is still ongoing on many of the
>>> topics that were discussed, it might be worth having workshop again this
>>> year to follow up, revise the plans if necessary, and discuss topics
>>> that were not covered last year.
>>>
>>> Before submitting a workshop proposal to the Ksummit PC I would like to
>>> probe the interest. IMO, it is important that we have scheduler
>>> maintainers present.
>>>
>>> Workshop topic proposals:
>>>
>>> Test cases
>>> Use-cases for high-end phones (which some of us care about) consist of
>>> rather complex software stacks which are not suitable for quick patch
>>> testing [3]. While we can't avoid testing using the full software stack
>>> in the end, it would be useful to have configurable micro-benchmarks for
>>> initial testing and to reproduce specific scheduling patterns from the
>>> full use-case for debugging purposes.
>>>
>>> Energy Evaluation
>>> A hot topic last year. We need a way to evaluate energy-awareness
>>> patches. Work has started on an idle state analysis tool [4], but we are
>>> not there yet.
>>>
>>
>> An interesting sub topic pertaining to evaluation would be deciding the
>> target residency of idle states. How do we know if the target residency
>> set for the different idle states is set optimally? The cpuidle governor
>> bases its decisions of the idle state to enter into based on numbers
>> such as these. If it is too stringent we would be hampering power savings.
>>
>> We could run different benchmarks with different degree of utilization.
>> And observe how much of the idle time is spent in different idle states.
>> If it is too less in a particular idle state we can up the target
>> residency of that idle state to begin with. This is static setting and
>> we hard code the target residency like now. Will a dynamic setting of
>> metrics like these help us in any way?
> 
> It might, as long as you are able to monitor energy in the kernel.
> target_residency is expressed in time, but must be evaluated in energy
> terms, it is a break-even point. It strictly depends on the dynamic state
> of the CPU when it goes idle, hence not really easy to factor in.
> 
> On ARM, it depends on a slew of factors, inclusive of the number of
> dirty caches lines (ie memory writebacks), running CPU frequency, memory
> frequency and the list goes on and on and on.
> 
> I am not even taking into account CPU idle states (C-states) whose power
> domains span devices such as GPUs.
> 
> It is certainly an interesting topic, I gave a presentation on this
> at Linaro Connect in 2013, I would be happy to share the results and debate
> it if I am able to attend.
> 
>> This was just an example to show that there are interesting problems
>> around "tuning" of power management metrics. It would be very helpful if
>> the maintainers relevant to this workshop guide us on this.
> 
> I would be certainly happy to explain to you how idle states work on ARM
> systems and the factors contributing to target_residency and other idle
> states parameters.

Thanks for sharing your ideas about this.

Lorenzo,
Sure I will be glad if we are able to meet to discuss this.

Amit,
I will take a look at idle stat and verify if I can use it for my purpose.

Regards
Preeti U Murthy
> 
> Thanks,
> Lorenzo
>