On 11/11/2013 05:36 PM, Peter Zijlstra wrote:
On Mon, Nov 11, 2013 at 11:33:45AM +, Catalin Marinas wrote:
tl;dr :-) Still trying to wrap my head around how to do that weird
topology Vincent raised..
Question for Peter/Ingo: do you want the scheduler to decide on which
C-state a CPU
On 11/11/2013 05:36 PM, Peter Zijlstra wrote:
On Mon, Nov 11, 2013 at 11:33:45AM +, Catalin Marinas wrote:
tl;dr :-) Still trying to wrap my head around how to do that weird
topology Vincent raised..
Question for Peter/Ingo: do you want the scheduler to decide on which
C-state a CPU
for picking the cpu to wake on there are also low level physical kind of things
we'd want to take into account on the intel side.
Are these static and could they be hidden behind some cost number in a
topology description? If they are dynamic, we would need arch or driver
hooks to give some
On Wed, Nov 13, 2013 at 04:13:57PM +, Arjan van de Ven wrote:
> On 11/12/2013 3:14 PM, Catalin Marinas wrote:
> > On 12 Nov 2013, at 16:48, Arjan van de Ven wrote:
> >> On 11/11/2013 10:18 AM, Catalin Marinas wrote:
> >>> The ordering is based on the actual C-state, so a simple way is to wake
On 11/12/2013 3:14 PM, Catalin Marinas wrote:
On 12 Nov 2013, at 16:48, Arjan van de Ven wrote:
On 11/11/2013 10:18 AM, Catalin Marinas wrote:
The ordering is based on the actual C-state, so a simple way is to wake
up the CPU in the shallowest C-state. With asymmetric configurations
On 11/12/2013 3:14 PM, Catalin Marinas wrote:
On 12 Nov 2013, at 16:48, Arjan van de Ven ar...@linux.intel.com wrote:
On 11/11/2013 10:18 AM, Catalin Marinas wrote:
The ordering is based on the actual C-state, so a simple way is to wake
up the CPU in the shallowest C-state. With asymmetric
On Wed, Nov 13, 2013 at 04:13:57PM +, Arjan van de Ven wrote:
On 11/12/2013 3:14 PM, Catalin Marinas wrote:
On 12 Nov 2013, at 16:48, Arjan van de Ven ar...@linux.intel.com wrote:
On 11/11/2013 10:18 AM, Catalin Marinas wrote:
The ordering is based on the actual C-state, so a simple way
for picking the cpu to wake on there are also low level physical kind of things
we'd want to take into account on the intel side.
Are these static and could they be hidden behind some cost number in a
topology description? If they are dynamic, we would need arch or driver
hooks to give some
On 12 Nov 2013, at 16:48, Arjan van de Ven wrote:
> On 11/11/2013 10:18 AM, Catalin Marinas wrote:
>> The ordering is based on the actual C-state, so a simple way is to wake
>> up the CPU in the shallowest C-state. With asymmetric configurations
>> (big.LITTLE) we have different costs for the
On Mon, Nov 11, 2013 at 04:36:30PM +, Peter Zijlstra wrote:
> On Mon, Nov 11, 2013 at 11:33:45AM +, Catalin Marinas wrote:
>
> tl;dr :-) Still trying to wrap my head around how to do that weird
> topology Vincent raised..
Long email, I know, but topology discussion is a good start ;).
On 11/11/2013 10:18 AM, Catalin Marinas wrote:
The ordering is based on the actual C-state, so a simple way is to wake
up the CPU in the shallowest C-state. With asymmetric configurations
(big.LITTLE) we have different costs for the same C-state, so this would
come in handy.
btw I was
On 11 November 2013 12:33, Catalin Marinas wrote:
> Hi Vincent,
>
> (cross-posting to linux-pm as it was agreed to follow up on this list)
>
>
> So, IMO, defining the power topology is a good starting point and I
> think it's better to separate the patches from the energy saving
> algorithms
On Mon, Nov 11, 2013 at 06:18:05PM +, Catalin Marinas wrote:
> On Mon, Nov 11, 2013 at 04:39:45PM +, Arjan van de Ven wrote:
> > having a hardware driver give a prefered CPU ordering for wakes can indeed
> > be useful.
> > (I'm doubtful that changing the recommendation for each idle is
On 11 November 2013 17:38, Peter Zijlstra wrote:
> On Mon, Nov 11, 2013 at 11:33:45AM +, Catalin Marinas wrote:
>> My understanding from the recent discussions is that the scheduler
>> should decide directly on the C-state (or rather the deepest C-state
>> possible since we don't want to
On 11 November 2013 17:38, Peter Zijlstra pet...@infradead.org wrote:
On Mon, Nov 11, 2013 at 11:33:45AM +, Catalin Marinas wrote:
My understanding from the recent discussions is that the scheduler
should decide directly on the C-state (or rather the deepest C-state
possible since we don't
On Mon, Nov 11, 2013 at 06:18:05PM +, Catalin Marinas wrote:
On Mon, Nov 11, 2013 at 04:39:45PM +, Arjan van de Ven wrote:
having a hardware driver give a prefered CPU ordering for wakes can indeed
be useful.
(I'm doubtful that changing the recommendation for each idle is going to
On 11 November 2013 12:33, Catalin Marinas catalin.mari...@arm.com wrote:
Hi Vincent,
(cross-posting to linux-pm as it was agreed to follow up on this list)
snip
So, IMO, defining the power topology is a good starting point and I
think it's better to separate the patches from the energy
On 11/11/2013 10:18 AM, Catalin Marinas wrote:
The ordering is based on the actual C-state, so a simple way is to wake
up the CPU in the shallowest C-state. With asymmetric configurations
(big.LITTLE) we have different costs for the same C-state, so this would
come in handy.
btw I was
On Mon, Nov 11, 2013 at 04:36:30PM +, Peter Zijlstra wrote:
On Mon, Nov 11, 2013 at 11:33:45AM +, Catalin Marinas wrote:
tl;dr :-) Still trying to wrap my head around how to do that weird
topology Vincent raised..
Long email, I know, but topology discussion is a good start ;).
To
On 12 Nov 2013, at 16:48, Arjan van de Ven ar...@linux.intel.com wrote:
On 11/11/2013 10:18 AM, Catalin Marinas wrote:
The ordering is based on the actual C-state, so a simple way is to wake
up the CPU in the shallowest C-state. With asymmetric configurations
(big.LITTLE) we have different
On 11 Nov 2013, at 19:26, Arjan van de Ven wrote:
> On 11/11/2013 10:31 AM, Catalin Marinas wrote:
>> I agree, we can't rely on the requested C-state but the_actual_ state
>> and this means querying the hardware driver. Can we abstract this via
>> some interface which provides the cost of waking
On Mon, 11 Nov 2013, Arjan van de Ven wrote:
> On 11/11/2013 10:31 AM, Catalin Marinas wrote:
> > I agree, we can't rely on the requested C-state but the_actual_ state
> > and this means querying the hardware driver. Can we abstract this via
> > some interface which provides the cost of waking
On 11/11/2013 10:31 AM, Catalin Marinas wrote:
I agree, we can't rely on the requested C-state but the_actual_ state
and this means querying the hardware driver. Can we abstract this via
some interface which provides the cost of waking up a CPU? This could
take into account the state of the
On Mon, Nov 11, 2013 at 04:54:54PM +, Morten Rasmussen wrote:
> On Mon, Nov 11, 2013 at 11:33:45AM +, Catalin Marinas wrote:
> > I would rather start by defining the main goal and working backwards
> > to an algorithm. We may as well find that task packing based on this
> > patch set is
On 11/11/2013 10:18 AM, Catalin Marinas wrote:
Even for symmetric configuration, the cost of moving a task to a CPU
includes wake-up cost plus the run-time cost which depends on the
P-state after wake-up (that's much trickier since we can't easily
estimate the cost of a P-state and it may
On Mon, Nov 11, 2013 at 04:39:45PM +, Arjan van de Ven wrote:
> > I think the scheduler simply wants to say: we expect to go idle for X
> > ns, we want a guaranteed wakeup latency of Y ns -- go do your thing.
>
> as long as Y normally is "large" or "infinity" that is ok ;-)
> (a smaller Y
On Mon, Nov 11, 2013 at 11:33:45AM +, Catalin Marinas wrote:
> Hi Vincent,
>
> (cross-posting to linux-pm as it was agreed to follow up on this list)
>
> On 18 October 2013 12:52, Vincent Guittot wrote:
> > This is the 5th version of the previously named "packing small tasks"
> > patchset.
I think the scheduler simply wants to say: we expect to go idle for X
ns, we want a guaranteed wakeup latency of Y ns -- go do your thing.
as long as Y normally is "large" or "infinity" that is ok ;-)
(a smaller Y will increase power consumption and decrease system performance)
I think
On 11/11/2013 8:38 AM, Peter Zijlstra wrote:
Like the package C states on x86 -- for those to be effective the
scheduler needs to pack tasks and keep entire packages idle for as long
as possible.
"package" C states on x86 are not really per package... but system wide.
the name is very
On Mon, Nov 11, 2013 at 11:33:45AM +, Catalin Marinas wrote:
> My understanding from the recent discussions is that the scheduler
> should decide directly on the C-state (or rather the deepest C-state
> possible since we don't want to duplicate the backend logic for
> synchronising CPUs going
On Mon, Nov 11, 2013 at 11:33:45AM +, Catalin Marinas wrote:
tl;dr :-) Still trying to wrap my head around how to do that weird
topology Vincent raised..
> Question for Peter/Ingo: do you want the scheduler to decide on which
> C-state a CPU should be in or we still leave this to a cpuidle
>
Hi Vincent,
(cross-posting to linux-pm as it was agreed to follow up on this list)
On 18 October 2013 12:52, Vincent Guittot wrote:
> This is the 5th version of the previously named "packing small tasks"
> patchset.
> "small" has been removed because the patchset doesn't only target small
Hi Vincent,
(cross-posting to linux-pm as it was agreed to follow up on this list)
On 18 October 2013 12:52, Vincent Guittot vincent.guit...@linaro.org wrote:
This is the 5th version of the previously named packing small tasks
patchset.
small has been removed because the patchset doesn't
On Mon, Nov 11, 2013 at 11:33:45AM +, Catalin Marinas wrote:
tl;dr :-) Still trying to wrap my head around how to do that weird
topology Vincent raised..
Question for Peter/Ingo: do you want the scheduler to decide on which
C-state a CPU should be in or we still leave this to a cpuidle
On Mon, Nov 11, 2013 at 11:33:45AM +, Catalin Marinas wrote:
My understanding from the recent discussions is that the scheduler
should decide directly on the C-state (or rather the deepest C-state
possible since we don't want to duplicate the backend logic for
synchronising CPUs going up
On 11/11/2013 8:38 AM, Peter Zijlstra wrote:
Like the package C states on x86 -- for those to be effective the
scheduler needs to pack tasks and keep entire packages idle for as long
as possible.
package C states on x86 are not really per package... but system wide.
the name is very confusing.
I think the scheduler simply wants to say: we expect to go idle for X
ns, we want a guaranteed wakeup latency of Y ns -- go do your thing.
as long as Y normally is large or infinity that is ok ;-)
(a smaller Y will increase power consumption and decrease system performance)
I think you
On Mon, Nov 11, 2013 at 11:33:45AM +, Catalin Marinas wrote:
Hi Vincent,
(cross-posting to linux-pm as it was agreed to follow up on this list)
On 18 October 2013 12:52, Vincent Guittot vincent.guit...@linaro.org wrote:
This is the 5th version of the previously named packing small
On Mon, Nov 11, 2013 at 04:39:45PM +, Arjan van de Ven wrote:
I think the scheduler simply wants to say: we expect to go idle for X
ns, we want a guaranteed wakeup latency of Y ns -- go do your thing.
as long as Y normally is large or infinity that is ok ;-)
(a smaller Y will increase
On 11/11/2013 10:18 AM, Catalin Marinas wrote:
Even for symmetric configuration, the cost of moving a task to a CPU
includes wake-up cost plus the run-time cost which depends on the
P-state after wake-up (that's much trickier since we can't easily
estimate the cost of a P-state and it may
On Mon, Nov 11, 2013 at 04:54:54PM +, Morten Rasmussen wrote:
On Mon, Nov 11, 2013 at 11:33:45AM +, Catalin Marinas wrote:
I would rather start by defining the main goal and working backwards
to an algorithm. We may as well find that task packing based on this
patch set is
On 11/11/2013 10:31 AM, Catalin Marinas wrote:
I agree, we can't rely on the requested C-state but the_actual_ state
and this means querying the hardware driver. Can we abstract this via
some interface which provides the cost of waking up a CPU? This could
take into account the state of the
On Mon, 11 Nov 2013, Arjan van de Ven wrote:
On 11/11/2013 10:31 AM, Catalin Marinas wrote:
I agree, we can't rely on the requested C-state but the_actual_ state
and this means querying the hardware driver. Can we abstract this via
some interface which provides the cost of waking up a
On 11 Nov 2013, at 19:26, Arjan van de Ven ar...@linux.intel.com wrote:
On 11/11/2013 10:31 AM, Catalin Marinas wrote:
I agree, we can't rely on the requested C-state but the_actual_ state
and this means querying the hardware driver. Can we abstract this via
some interface which provides the
This is the 5th version of the previously named "packing small tasks" patchset.
"small" has been removed because the patchset doesn't only target small tasks
anymore.
This patchset takes advantage of the new per-task load tracking that is
available in the scheduler to pack the tasks in a minimum
This is the 5th version of the previously named packing small tasks patchset.
small has been removed because the patchset doesn't only target small tasks
anymore.
This patchset takes advantage of the new per-task load tracking that is
available in the scheduler to pack the tasks in a minimum
46 matches
Mail list logo
