Re: [RFC PATCH] sched: find the latest idle cpu

From: Daniel Lezcano
Date: Thu Jan 16 2014 - 07:16:23 EST


On 01/16/2014 12:38 PM, Peter Zijlstra wrote:
On Thu, Jan 16, 2014 at 12:03:13PM +0100, Daniel Lezcano wrote:
Hi Alex,

it is a nice optimization attempt but I agree with Peter we should focus on
integrating cpuidle.

The question is "how do we integrate cpuidle ?"

IMHO, the main problem are the governors, especially the menu governor.

Yah.

The menu governor tries to predict the events per cpu. This approach which
gave us a nice benefit for the power saving may not fit well for the
scheduler.

So the way to start all this is I think to gradually share more and
more.

Start by pulling in the actual idle state; such that we can indeed
observe what the relative cost is of waking a cpu (against another), and
maybe even the predicted wakeup time.

Ok, I will send a patch for this.

Then pull in the various statistics gathering bits -- without improving
them.

Then improve the statistics; try and remove duplicate statistics -- if
there's such things, try and use the extra information the scheduler has
etc..

Then worry about the governors, or what's left of them.

In order to finish integrating the cpuidle framework in the scheduler, there
are pending questions about the impact in the current design.

Peter or Ingo, if you have time, could you have a look at the email I sent
previously [1] ?

I read it once, it didn't make sense at the time, I just read it again,
still doesn't make sense.

:)

The question raised when I looked closely how to fully integrate cpuidle with the scheduler; in particular, the idle time.
The scheduler idle time is not the same than the cpuidle idle time.
A cpu can be idle for the scheduler 1s but it could be interrupted several times by an interrupt thus the idle time for cpuidle is different. But anyway ...

We need the idle task, since we need to DO something to go idle, the
scheduler needs to pick a task to go do that something. This is the idle
task.

You cannot get rid of that.

In fact, the 'doing' of that task is running much of the cpuidle code,
so by getting rid of it, there's nobody left to execute that code.

Also, since its already running that cpuidle stuff, integrating it more
closely with the scheduler will not in fact change much, it will still
run it.

Could of course be I'm not reading what you meant to write, if so, do
try again ;-)

Well, I wanted to have a clarification of what was your feeling about how to integrate cpuidle in the scheduler. If removing the idle task (in the future) does not make sense for you, I will not insist. Let's see how the code evolves by integrating cpuidle and we will figure out what will be the impact on the idle task.

Thanks for your feedbacks

-- Daniel

--
<http://www.linaro.org/> Linaro.org â Open source software for ARM SoCs

Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/