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 should
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 co
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
(big.LITTL
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 same
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 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 consideri
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 li
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 goi
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 dupli
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 up
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 othe
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 suf
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 chang
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
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 you
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
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 u
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 tasks
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
23 matches
Mail list logo