[Ksummit-discuss] Energy-aware Scheduling Workshop

[Lorenzo Pieralisi]

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,
Lorenzo