Re: Power Scheduler Design

Quoting Abel Vesa (2014-09-07 04:47:13) > For a while now, I've started studying the power aware scheduling problem. > And like many other rookies out there I took all the lkml mails related > and read them all (well, almost all) and I saw that there are some > debating on the implementation.I even

Re: Power Scheduler Design

于 9/7/14, 4:47, Abel Vesa 写道: For a while now, I've started studying the power aware scheduling problem. And like many other rookies out there I took all the lkml mails related and read them all (well, almost all) and I saw that there are some debating on the implementation.I even look over the

Power Scheduler Design

For a while now, I've started studying the power aware scheduling problem. And like many other rookies out there I took all the lkml mails related and read them all (well, almost all) and I saw that there are some debating on the implementation.I even look over the implementation proposed of Preeti

[RFC PATCH V2 00/19] Power Scheduler Design

ient scheduling design was posted by Morten after Ingo posted his suggestions on http://lwn.net/Articles/552889/. [RFC][PATCH 0/9] sched: Power scheduler design proposal: https://lkml.org/lkml/2013/7/15/101 But it decoupled the scheduler into the regular and power scheduler with the latter controllin

Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal

On Wed, Jul 24, 2013 at 05:48:42PM +0100, Arjan van de Ven wrote: > > > > I would expect performance to be disjoint for most tasks. If there was > > an overlap, the big would probably be less power efficient (as in > > energy/instruction) than the little so you would prefer to run on the > > little

Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal

I would expect performance to be disjoint for most tasks. If there was an overlap, the big would probably be less power efficient (as in energy/instruction) than the little so you would prefer to run on the little anyway. In what way would you use the overlap? if the scheduler thinks a task wo

Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal

On Wed, Jul 24, 2013 at 04:16:36PM +0100, Arjan van de Ven wrote: > > > Given that the power topology is taken into account, a sort > > left/right-like mechanism would only help performance insensitive tasks > > on big.LITTLE. Performance sensitive tasks that each can use more than > > a little cp

Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal

Given that the power topology is taken into account, a sort left/right-like mechanism would only help performance insensitive tasks on big.LITTLE. Performance sensitive tasks that each can use more than a little cpu should move in the opposite direction. Well, directly to a big cpu, even if some

Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal

On Wed, Jul 17, 2013 at 03:14:26PM +0100, Catalin Marinas wrote: > On Tue, Jul 16, 2013 at 04:23:08PM +0100, Arjan van de Ven wrote: > > On 7/16/2013 5:42 AM, Catalin Marinas wrote: > > > Morten's power scheduler tries to address the above and it will grow > > > into controlling a new model of powe

Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal

On Sat, Jul 13, 2013 at 07:49:09AM +0100, Peter Zijlstra wrote: > On Tue, Jul 09, 2013 at 04:55:29PM +0100, Morten Rasmussen wrote: > > Hi, > > > > This patch set is an initial prototype aiming at the overall power-aware > > scheduler design proposal that I previously described > >

Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal

On Tue, Jul 16, 2013 at 04:23:08PM +0100, Arjan van de Ven wrote: > On 7/16/2013 5:42 AM, Catalin Marinas wrote: > > Morten's power scheduler tries to address the above and it will grow > > into controlling a new model of power driver (and taking into account > > Arjan's and others' comments regard

Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal

On Mon, 15 Jul 2013, Arjan van de Ven wrote: On 7/15/2013 2:03 PM, Peter Zijlstra wrote: Well, if you ever want to go faster there must've been a moment to slow down. Without means and reason to slow down the entire 'can I go fast noaw pls?' thing simply doesn't make sense. I kind of tried t

Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal

On 7/16/2013 1:17 PM, Peter Zijlstra wrote: On Tue, Jul 16, 2013 at 12:57:34PM -0700, Arjan van de Ven wrote: then the question of how much remaining capacity; this is a hard one, and not just for Intel. Almost all mobile devices today are thermally constrained, ARM and Intel alike (at least t

Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal

On 7/16/2013 1:17 PM, Peter Zijlstra wrote: On Tue, Jul 16, 2013 at 12:57:34PM -0700, Arjan van de Ven wrote: then the question of how much remaining capacity; this is a hard one, and not just for Intel. Almost all mobile devices today are thermally constrained, ARM and Intel alike (at least t

Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal

On Tue, Jul 16, 2013 at 12:57:34PM -0700, Arjan van de Ven wrote: > then the question of how much remaining capacity; this is a hard one, and not > just > for Intel. Almost all mobile devices today are thermally constrained, ARM and > Intel > alike (at least the higher performance ones)... the cu

Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal

On 7/16/2013 12:21 PM, Peter Zijlstra wrote: Suppose a 2 cpu system, one cpu is running 3/4 throttle, the other is running at half speed. Both cpus are equally utilized. A new task comes on. Where do we run it? We need to know that there's head-room on the 1/2 speed cpu and should crank its pa

Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal

On Tue, Jul 16, 2013 at 11:44:15AM -0700, Arjan van de Ven wrote: > the interaction is "using the scheduler data using the scheduler provided > function". I'm so not following. > So I don't just want something that makes sense for todays Intel ;-) > We need something that has an interface that m

Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal

On 7/16/2013 10:38 AM, Peter Zijlstra wrote: On Mon, Jul 15, 2013 at 03:52:32PM -0700, Arjan van de Ven wrote: yeah ondemand does this, but ondemand is actually a pretty bad governor. not because of the sampling, but because of its algorithm. Is it good for any class of hardware still out the

Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal

On Mon, Jul 15, 2013 at 03:52:32PM -0700, Arjan van de Ven wrote: > yeah ondemand does this, but ondemand is actually a pretty bad governor. > not because of the sampling, but because of its algorithm. Is it good for any class of hardware still out there? Or should the thing be shot in the head?

Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal

On 7/16/2013 5:42 AM, Catalin Marinas wrote: Morten's power scheduler tries to address the above and it will grow into controlling a new model of power driver (and taking into account Arjan's and others' comments regarding the API). At the same time, we need some form of task packing. The power s

Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal

On Mon, Jul 15, 2013 at 09:39:22PM +0100, Peter Zijlstra wrote: > On Sat, Jul 13, 2013 at 11:23:51AM +0100, Catalin Marinas wrote: > > > This looks like a userspace hotplug deamon approach lifted to kernel > > > space :/ > > > > The difference is that this is faster. We even had hotplug in mind s

Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal

On 7/15/2013 2:12 PM, Peter Zijlstra wrote: On Mon, Jul 15, 2013 at 11:06:50PM +0200, Peter Zijlstra wrote: OK, but isn't that part of why the micro controller might not make you go faster even if you do program a higher P state? But yes, I understand this issue in the 'traditional' cpufreq sen

Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal

so depending of the mix of compute and memory instructions, different tradeoffs might be needed. (for an example of this, AMD exposes a CPU counter for this as of recently and added patches to "ondemand" to use it) OK, but isn't that part of why the micro controller might not make you go fas

Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal

On 7/15/2013 2:03 PM, Peter Zijlstra wrote: Well, if you ever want to go faster there must've been a moment to slow down. Without means and reason to slow down the entire 'can I go fast noaw pls?' thing simply doesn't make sense. I kind of tried to hint at this there's either go_fastest_now()

Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal

On Mon, Jul 15, 2013 at 11:06:50PM +0200, Peter Zijlstra wrote: > OK, but isn't that part of why the micro controller might not make you go > faster even if you do program a higher P state? > > But yes, I understand this issue in the 'traditional' cpufreq sense. There's > no > point in ramping th

Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal

On Mon, Jul 15, 2013 at 01:41:47PM -0700, Arjan van de Ven wrote: > On 7/15/2013 12:59 PM, Peter Zijlstra wrote: > >On Sat, Jul 13, 2013 at 07:40:08AM -0700, Arjan van de Ven wrote: > >>On 7/12/2013 11:49 PM, Peter Zijlstra wrote: > >>> > >>>Arjan; from reading your emails you're mostly busy explai

Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal

On Mon, Jul 15, 2013 at 01:37:44PM -0700, Arjan van de Ven wrote: > On 7/15/2013 12:59 PM, Peter Zijlstra wrote: > > >>this is where it gets complicated ;-( the race-to-idle depends on the type > >>of > >>code that is running, if things are memory bound it's outright not true, but > >>for compute

Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal

On 7/15/2013 12:59 PM, Peter Zijlstra wrote: On Sat, Jul 13, 2013 at 07:40:08AM -0700, Arjan van de Ven wrote: On 7/12/2013 11:49 PM, Peter Zijlstra wrote: Arjan; from reading your emails you're mostly busy explaining what cannot be done. Please explain what _can_ be done and what Intel wants.

Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal

On Sat, Jul 13, 2013 at 11:23:51AM +0100, Catalin Marinas wrote: > > This looks like a userspace hotplug deamon approach lifted to kernel space > > :/ > > The difference is that this is faster. We even had hotplug in mind some > years ago for big.LITTLE but it wouldn't give the performance we nee

Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal

On 7/15/2013 12:59 PM, Peter Zijlstra wrote: this is where it gets complicated ;-( the race-to-idle depends on the type of code that is running, if things are memory bound it's outright not true, but for compute bound it often is. So you didn't actually answer the question about when you'd pro

Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal

On Sat, Jul 13, 2013 at 07:40:08AM -0700, Arjan van de Ven wrote: > On 7/12/2013 11:49 PM, Peter Zijlstra wrote: > > > >Arjan; from reading your emails you're mostly busy explaining what cannot be > >done. Please explain what _can_ be done and what Intel wants. From what I can > >see you basically

Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal

On 7/15/2013 2:55 AM, Catalin Marinas wrote: In terms of how it boosts the performance, a suggestion was to keep the power scheduler relatively simple with an API to a new model of power driver and have the actual scaling algorithm (governor) as library used by the low-level driver. We can keep t

Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal

ly go up or down one step at the time. Much like the existing > > conservative cpufreq governor that nobody uses. Maybe I am missing > > something? > > > > I think we should look into scaling the tracked load by some metric that > > represents the current performance of

Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal

On 13 July 2013 12:23, Catalin Marinas wrote: > Hi Peter, > > (Morten's away for a week, I'll try cover some bits in the meantime) > > On Sat, Jul 13, 2013 at 07:49:09AM +0100, Peter Zijlstra wrote: >> On Tue, Jul 09, 2013 at 04:55:29PM +0100, Morten Rasmussen wrote: >> > This patch set is an init

Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal

lve that problem. It would just make frequency scaling slower if you > only go up or down one step at the time. Much like the existing > conservative cpufreq governor that nobody uses. Maybe I am missing > something? > > I think we should look into scaling the tracked load by some me

Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal

On 07/14/2013 12:14 AM, Arjan van de Ven wrote: > > > on thinking more about the short running task thing; there is an > optimization we currently don't do, > mostly for hyperthreading. (and HT is just one out of a set of cases > with similar power behavior) > If we know a task runs briefly AND i

Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal

On 7/12/2013 11:49 PM, Peter Zijlstra wrote: On Tue, Jul 09, 2013 at 04:55:29PM +0100, Morten Rasmussen wrote: Hi, This patch set is an initial prototype aiming at the overall power-aware scheduler design proposal that I previously described

Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal

On 7/12/2013 11:49 PM, Peter Zijlstra wrote: Arjan; from reading your emails you're mostly busy explaining what cannot be done. Please explain what _can_ be done and what Intel wants. From what I can see you basically promote a max P state max concurrency race to idle FTW. Since you can't sa

Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal

Hi Peter, (Morten's away for a week, I'll try cover some bits in the meantime) On Sat, Jul 13, 2013 at 07:49:09AM +0100, Peter Zijlstra wrote: > On Tue, Jul 09, 2013 at 04:55:29PM +0100, Morten Rasmussen wrote: > > This patch set is an initial prototype aiming at the overall power-aware > > sched

Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal

On Tue, Jul 09, 2013 at 04:55:29PM +0100, Morten Rasmussen wrote: > Hi, > > This patch set is an initial prototype aiming at the overall power-aware > scheduler design proposal that I previously described > . > > The patch set introduces a cp

Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal

But on x86 you still have a P-state hint for the CPU and the scheduler could at least hope for more CPU performance. We can make the power scheduler ask the power driver for an increase or decrease of performance (as Preeti suggested) and give it the current load as argument rather than a precis

Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal

On 7/12/2013 5:46 AM, Morten Rasmussen wrote: I have had a quick look at intel_pstate.c and to me it seems that it can be turned into a power driver that uses the proposed interface with a few modifications. intel_pstate.c already has max and min P-state as well as a current P-state calculated

Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal

ent one. I don't understand how a simple up/down request from the scheduler would solve that problem. It would just make frequency scaling slower if you only go up or down one step at the time. Much like the existing conservative cpufreq governor that nobody uses. Maybe I am missing something

Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal

On Tue, Jul 09, 2013 at 05:58:55PM +0100, Arjan van de Ven wrote: > On 7/9/2013 8:55 AM, Morten Rasmussen wrote: > > This patch set is an initial prototype aiming at the overall power-aware > > scheduler design proposal that I previously described > >

Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal

On Wed, Jul 10, 2013 at 02:05:00PM +0100, Arjan van de Ven wrote: > >> also, it almost looks like there is a fundamental assumption in the > >> code that you can get the current effective P state to make > >> scheduler decisions on; on Intel at least that is basically > >> impossible... and getting

Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal

On Wed, Jul 10, 2013 at 02:05:00PM +0100, Arjan van de Ven wrote: > > > > >> > >> also, it almost looks like there is a fundamental assumption in the code > >> that you can get the current effective P state to make scheduler decisions > >> on; > >> on Intel at least that is basically impossible..

Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal

Hi Morten, I have a few quick comments. On 07/09/2013 10:28 PM, Arjan van de Ven wrote: > On 7/9/2013 8:55 AM, Morten Rasmussen wrote: >> Hi, >> >> This patch set is an initial prototype aiming at the overall power-aware >> scheduler design proposal that I previously described >>

Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal

also, it almost looks like there is a fundamental assumption in the code that you can get the current effective P state to make scheduler decisions on; on Intel at least that is basically impossible... and getting more so with every generation (likewise for AMD afaics) (you can get what you

Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal

On Tue, Jul 09, 2013 at 05:58:55PM +0100, Arjan van de Ven wrote: > On 7/9/2013 8:55 AM, Morten Rasmussen wrote: > > Hi, > > > > This patch set is an initial prototype aiming at the overall power-aware > > scheduler design proposal that I previously described > >

Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal

On 7/9/2013 8:55 AM, Morten Rasmussen wrote: Hi, This patch set is an initial prototype aiming at the overall power-aware scheduler design proposal that I previously described . The patch set introduces a cpu capacity managing 'power schedu

[RFC][PATCH 0/9] sched: Power scheduler design proposal

Hi, This patch set is an initial prototype aiming at the overall power-aware scheduler design proposal that I previously described . The patch set introduces a cpu capacity managing 'power scheduler' which lives by the side of the existing (p