On Tue, Apr 23, 2013 at 08:30:58AM -0700, Arjan van de Ven wrote:
> For x86 we should not be setting such flag then; we don't have a way for some
> cpu packages to
> go to an extra deep power state if they're completely idle.
> (this afaik is true for both Intel and AMD)
You say 'some'; this
On Tue, Apr 23, 2013 at 08:30:58AM -0700, Arjan van de Ven wrote:
For x86 we should not be setting such flag then; we don't have a way for some
cpu packages to
go to an extra deep power state if they're completely idle.
(this afaik is true for both Intel and AMD)
You say 'some'; this implies
On 4/22/2013 7:23 PM, Alex Shi wrote:
Thanks you, Preeti and Vincent to talk the power aware scheduler for
details! believe this open discussion is helpful to conduct a a more
comprehensive solution. :)
Hi Preeti,
I have had a look at Alex patches but i have some concerns with his patches
On 4/22/2013 7:23 PM, Alex Shi wrote:
Thanks you, Preeti and Vincent to talk the power aware scheduler for
details! believe this open discussion is helpful to conduct a a more
comprehensive solution. :)
Hi Preeti,
I have had a look at Alex patches but i have some concerns with his patches
Hi Alex,
I have one point below.
On 04/23/2013 07:53 AM, Alex Shi wrote:
> Thanks you, Preeti and Vincent to talk the power aware scheduler for
> details! believe this open discussion is helpful to conduct a a more
> comprehensive solution. :)
>
>> Hi Preeti,
>>
>> I have had a look at Alex
Hi Vincent,
Thank you very much for bringing about the differences between your
goals and the working of the power aware scheduler patchset.This was
essential for us to understand the various requirements from a power
aware scheduler.After you post out the patchset we could try and
evaluate the
Thanks you, Preeti and Vincent to talk the power aware scheduler for
details! believe this open discussion is helpful to conduct a a more
comprehensive solution. :)
> Hi Preeti,
>
> I have had a look at Alex patches but i have some concerns with his patches
> -There no notion of power domain
Thanks you, Preeti and Vincent to talk the power aware scheduler for
details! believe this open discussion is helpful to conduct a a more
comprehensive solution. :)
Hi Preeti,
I have had a look at Alex patches but i have some concerns with his patches
-There no notion of power domain which
Hi Vincent,
Thank you very much for bringing about the differences between your
goals and the working of the power aware scheduler patchset.This was
essential for us to understand the various requirements from a power
aware scheduler.After you post out the patchset we could try and
evaluate the
Hi Alex,
I have one point below.
On 04/23/2013 07:53 AM, Alex Shi wrote:
Thanks you, Preeti and Vincent to talk the power aware scheduler for
details! believe this open discussion is helpful to conduct a a more
comprehensive solution. :)
Hi Preeti,
I have had a look at Alex patches but i
Hi Vincent,
On 04/05/2013 04:38 PM, Vincent Guittot wrote:
> Peter,
>
> After some toughts about your comments,I can update the buddy cpu
> during ILB or periofdic LB to a new idle core and extend the packing
> mechanism Does this additional mechanism sound better for you ?
If the primary goal
Hi Vincent,
On 04/05/2013 04:38 PM, Vincent Guittot wrote:
Peter,
After some toughts about your comments,I can update the buddy cpu
during ILB or periofdic LB to a new idle core and extend the packing
mechanism Does this additional mechanism sound better for you ?
If the primary goal of
Peter,
After some toughts about your comments,I can update the buddy cpu
during ILB or periofdic LB to a new idle core and extend the packing
mechanism Does this additional mechanism sound better for you ?
Vincent
On 26 March 2013 15:42, Peter Zijlstra wrote:
> On Tue, 2013-03-26 at 15:03
Peter,
After some toughts about your comments,I can update the buddy cpu
during ILB or periofdic LB to a new idle core and extend the packing
mechanism Does this additional mechanism sound better for you ?
Vincent
On 26 March 2013 15:42, Peter Zijlstra pet...@infradead.org wrote:
On Tue,
On 03/27/2013 06:30 PM, Vincent Guittot wrote:
>> Arguing the performance/power balance does no much sense without
>> > detailed scenario. We just want to seek a flexible compromise way.
>> > But fixed buddy cpu is not flexible. and it may lose many possible
>> > powersaving fit scenarios on x86
On 27 March 2013 09:47, Alex Shi wrote:
>
>> So supposing the current ILB is 6, we'll only check 4, not 0-3, even
>> though there might be a perfectly idle cpu in there.
We will check 4,5,7 at MC level in order to pack in the group of A15
(because they are not sharing the same
On Wed, 2013-03-27 at 12:56 +0800, Alex Shi wrote:
> Just one buddy to pack tasks for whole level cpus definitely has
> scalability problem.
Right, but note we already have this scalability problem in the form of
the ILB. Some people were working on sorting that but then someone
changed jobs and
> So supposing the current ILB is 6, we'll only check 4, not 0-3, even
> though there might be a perfectly idle cpu in there.
>>> We will check 4,5,7 at MC level in order to pack in the group of A15
>>> (because they are not sharing the same power domain). If none of them
>>> are idle, we
On 27 March 2013 05:56, Alex Shi wrote:
> On 03/26/2013 11:55 PM, Vincent Guittot wrote:
>>> > So extrapolating that to a 4+4 big-little you'd get something like:
>>> >
>>> > | little A9 || big A15 |
>>> > | 0 | 1 | 2 | 3 || 4 | 5 | 6 | 7 |
>>> >
On 27 March 2013 05:56, Alex Shi alex@intel.com wrote:
On 03/26/2013 11:55 PM, Vincent Guittot wrote:
So extrapolating that to a 4+4 big-little you'd get something like:
| little A9 || big A15 |
| 0 | 1 | 2 | 3 || 4 | 5 | 6 | 7 |
So supposing the current ILB is 6, we'll only check 4, not 0-3, even
though there might be a perfectly idle cpu in there.
We will check 4,5,7 at MC level in order to pack in the group of A15
(because they are not sharing the same power domain). If none of them
are idle, we will look at CPU
On Wed, 2013-03-27 at 12:56 +0800, Alex Shi wrote:
Just one buddy to pack tasks for whole level cpus definitely has
scalability problem.
Right, but note we already have this scalability problem in the form of
the ILB. Some people were working on sorting that but then someone
changed jobs and I
On 27 March 2013 09:47, Alex Shi alex@intel.com wrote:
So supposing the current ILB is 6, we'll only check 4, not 0-3, even
though there might be a perfectly idle cpu in there.
We will check 4,5,7 at MC level in order to pack in the group of A15
(because they are not sharing the same
On 03/27/2013 06:30 PM, Vincent Guittot wrote:
Arguing the performance/power balance does no much sense without
detailed scenario. We just want to seek a flexible compromise way.
But fixed buddy cpu is not flexible. and it may lose many possible
powersaving fit scenarios on x86 system. Like
On 03/26/2013 11:55 PM, Vincent Guittot wrote:
>> > So extrapolating that to a 4+4 big-little you'd get something like:
>> >
>> > | little A9 || big A15 |
>> > | 0 | 1 | 2 | 3 || 4 | 5 | 6 | 7 |
>> > --+---+---+---+---++---+---+---+---+
>> > buddy | 0 | 0 | 0 | 0 || 0 | 4
On 26 March 2013 15:42, Peter Zijlstra wrote:
> On Tue, 2013-03-26 at 15:03 +0100, Vincent Guittot wrote:
>> > But ha! here's your NO_HZ link.. but does the above DTRT and ensure
>> > that the ILB is a little core when possible?
>>
>> The loop looks for an idle CPU as close as possible to the
On Tue, 2013-03-26 at 15:03 +0100, Vincent Guittot wrote:
> > But ha! here's your NO_HZ link.. but does the above DTRT and ensure
> > that the ILB is a little core when possible?
>
> The loop looks for an idle CPU as close as possible to the buddy CPU
> and the buddy CPU is the 1st CPU has been
On 26 March 2013 13:52, Peter Zijlstra wrote:
> On Fri, 2013-03-22 at 13:25 +0100, Vincent Guittot wrote:
>> Look for an idle CPU close to the pack buddy CPU whenever possible.
>> The goal is to prevent the wake up of a CPU which doesn't share the
>> power
>> domain of the pack buddy CPU.
>>
>>
On Fri, 2013-03-22 at 13:25 +0100, Vincent Guittot wrote:
> Look for an idle CPU close to the pack buddy CPU whenever possible.
> The goal is to prevent the wake up of a CPU which doesn't share the
> power
> domain of the pack buddy CPU.
>
> Signed-off-by: Vincent Guittot
> Reviewed-by: Morten
On Fri, 2013-03-22 at 13:25 +0100, Vincent Guittot wrote:
Look for an idle CPU close to the pack buddy CPU whenever possible.
The goal is to prevent the wake up of a CPU which doesn't share the
power
domain of the pack buddy CPU.
Signed-off-by: Vincent Guittot vincent.guit...@linaro.org
On 26 March 2013 13:52, Peter Zijlstra pet...@infradead.org wrote:
On Fri, 2013-03-22 at 13:25 +0100, Vincent Guittot wrote:
Look for an idle CPU close to the pack buddy CPU whenever possible.
The goal is to prevent the wake up of a CPU which doesn't share the
power
domain of the pack buddy
On Tue, 2013-03-26 at 15:03 +0100, Vincent Guittot wrote:
But ha! here's your NO_HZ link.. but does the above DTRT and ensure
that the ILB is a little core when possible?
The loop looks for an idle CPU as close as possible to the buddy CPU
and the buddy CPU is the 1st CPU has been chosen.
On 26 March 2013 15:42, Peter Zijlstra pet...@infradead.org wrote:
On Tue, 2013-03-26 at 15:03 +0100, Vincent Guittot wrote:
But ha! here's your NO_HZ link.. but does the above DTRT and ensure
that the ILB is a little core when possible?
The loop looks for an idle CPU as close as possible
On 03/26/2013 11:55 PM, Vincent Guittot wrote:
So extrapolating that to a 4+4 big-little you'd get something like:
| little A9 || big A15 |
| 0 | 1 | 2 | 3 || 4 | 5 | 6 | 7 |
--+---+---+---+---++---+---+---+---+
buddy | 0 | 0 | 0 | 0 || 0 | 4 | 4 | 4 |
Look for an idle CPU close to the pack buddy CPU whenever possible.
The goal is to prevent the wake up of a CPU which doesn't share the power
domain of the pack buddy CPU.
Signed-off-by: Vincent Guittot
Reviewed-by: Morten Rasmussen
---
kernel/sched/fair.c | 18 ++
1 file
Look for an idle CPU close to the pack buddy CPU whenever possible.
The goal is to prevent the wake up of a CPU which doesn't share the power
domain of the pack buddy CPU.
Signed-off-by: Vincent Guittot vincent.guit...@linaro.org
Reviewed-by: Morten Rasmussen morten.rasmus...@arm.com
---
36 matches
Mail list logo
