[Ksummit-2013-discuss] [ATTEND] Power-aware scheduling

[Preeti U Murthy]

Hi,

On 07/12/2013 09:06 PM, Morten Rasmussen wrote:
> Hi,
> 
> I'm working on the scheduler and integration of power management
> frameworks (cpuidle and cpufreq) with the scheduler. I have recently
> proposed power scheduler design that tries to address the issues
> discussed on LKML lately:
> 
> https://lkml.org/lkml/2013/6/14/307
> https://lkml.org/lkml/2013/7/9/314
> 
> I would like to discuss that and any related topic at the upcoming
> Kernel Summit.
> 
> Kind regards,
> Morten

Now that there are two topics proposed around scheduling (power aware
scheduling and integrating cpuidle, cpufreq and scheduler), I would like
to bring out a point related to the enhancements that are being proposed
for the scheduler.It would be great to have the below point discussed
too if most of the developers find it an issue.

One of the recent discussions in scheduler have been around using the
per-entity load tracking metric in load balancing. This was to observe
if improving the performance of the scheduler would in addition get us
power benefits. One of the discussions that I had around this can be
found here: https://lkml.org/lkml/2013/1/1/89

While working on this issue, I noticed that, if we intend to observe the
behaviour of the scheduler with some clarity, we would have to restrict
the total number of cpus to very few. Else it is hard to understand how
the scheduler is behaving.

Besides,*how* do we evaluate the behaviour of the scheduler? Do we use
perf sched to observe load balancing, do we rely only on the output of
benchmarks, what statistics in schedstat do we observe to find if all is
well in the scheduler or do we do all of the above?

What are the primary benchmarks to run? The performance might
drop on a few, but might be good on a few others. Since the scheduler
cannot get it all right, there must be some primary benchmarks whose
performance we must care about most and effort should be to make sure
scheduling works in the favour of their performance, and that should be
good enough. Besides having observed all of these, what do we compare
these statistics with to see if we can do better?

The point I am trying to make is when a new feature has to be introduced
into the scheduler, we need to first make sure that the existing
implementation of the scheduler has some issue that this new feature is
trying to fix. How do we reliably find that out?

Power aware scheduling is one such enhancement that we have been trying
to add into the scheduler. However we seem to be missing certain pieces
here, and a new proposal to integrate cpuidle, cpufreq and scheduler was
discussed.:https://lkml.org/lkml/2013/5/30/257. A kernel summit proposal
around this has been made too.

We did have a lot of discussions around this, with each theorizing the
potential advantages/disadvantages involved with doing this integration.
But how has it been proved that the existing implementation of having
three different sub systems doing
power management is flawed?

The approach to enhancing the functionalities of the scheduler would
sound convincing if we find problems either through numbers or some kind
of profiling in the existing implementation, and we set out to solve
exactly that problem. But doing this seems to be a task in itself due to
the challenge of having to answer the questions mentioned in the
paragraph above.
Or is the best way to find flaws in the existing implementation of the
scheduler, from a design point of view alone?

I would be very glad if the core scheduler maintainers participate in
this discussion, so as to guide some of us working towards scheduler
enhancement, so that we target the right problem.

It is at this time of so much activity and newer scheduler developers
entering the arena that we most need the guidance of scheduler
maintainers and the active scheduler developers to come together to
discuss these issues.

Regards
Preeti U Murthy