Messages in this thread | | | Date | Thu, 16 Jan 2014 13:16:12 +0100 | From | Daniel Lezcano <> | Subject | Re: [RFC PATCH] sched: find the latest idle cpu |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |