From: Ingo Molnar <mingo@elte.hu>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: vatsa@in.ibm.com, Martin Schwidefsky <schwidefsky@de.ibm.com>,
george@mvista.com, jdike@addtoit.com,
Jesse Barnes <jesse.barnes@intel.com>,
linux-kernel@vger.kernel.org, Lee Revell <rlrevell@joe-job.com>,
Tony Lindgren <tony@atomide.com>
Subject: Re: [RFC] (How to) Let idle CPUs sleep
Date: Fri, 13 May 2005 10:04:24 +0200 [thread overview]
Message-ID: <20050513080424.GA31206@elte.hu> (raw)
In-Reply-To: <42845456.3080908@yahoo.com.au>
* Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> > From all the discussions we have been having, I think a watchdog
> > implementation makes more sense. Nick/Ingo, what do you think
> > should be our final decision on this?
>
> Well the complex solution won't go in until it is shown that the
> simple version has fundamental failure cases - but I don't think we
> need to make a final decision yet do we?
there's no need to make a final decision yet. But the more complex
watchdog solution does have the advantage of putting idle CPUs to sleep
immediately and perpetually.
the power equation is really easy: the implicit cost of a deep CPU sleep
is say 1-2 msecs. (that's how long it takes to shut the CPU and the bus
down, etc.) If we do an exponential backoff we periodically re-wake the
CPU fully up again - wasting 1-2msec (or more) more power. With the
watchdog solution we have more overhead on the busy CPU but it takes
_much_ less power for a truly idle CPU to be turned off. [the true
'effective cost' all depends on the scheduling pattern as well, but the
calculation before is still valid.] Whatever the algorithmic overhead of
the watchdog code, it's dwarved by the power overhead caused by false
idle-wakeups of CPUs under exponential backoff.
the watchdog solution - despite being more complex - is also more
orthogonal in that it does not change the balancing decisions at all -
they just get offloaded to another CPU. The exponential backoff OTOH
materially changes how we do SMP balancing - which might or might not
matter much, but it will always depend on circumstances. So in the long
run the watchdog solution is probably easier to control. (because it's
just an algorithm offload, not a material scheduling feature.)
so unless there are strong implementational arguments against the
watchdog solution, i definitely think it's the higher quality solution,
both in terms of power savings, and in terms of impact.
Ingo
next prev parent reply other threads:[~2005-05-13 8:05 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-07 18:27 [uml-devel] [RFC] (How to) Let idle CPUs sleep Srivatsa Vaddagiri
2005-05-07 18:27 ` Srivatsa Vaddagiri
2005-05-08 3:50 ` [uml-devel] " Rusty Russell
2005-05-08 3:50 ` Rusty Russell
2005-05-08 4:14 ` [uml-devel] " Nick Piggin
2005-05-08 4:14 ` Nick Piggin
2005-05-08 12:19 ` [uml-devel] " Srivatsa Vaddagiri
2005-05-08 12:19 ` Srivatsa Vaddagiri
2005-05-09 6:27 ` [uml-devel] " Nick Piggin
2005-05-09 6:27 ` Nick Piggin
2005-05-12 8:38 ` Srivatsa Vaddagiri
2005-05-11 18:03 ` [uml-devel] " Tony Lindgren
2005-05-11 18:03 ` Tony Lindgren
2005-05-12 8:46 ` Srivatsa Vaddagiri
2005-05-12 16:01 ` Lee Revell
2005-05-12 16:16 ` Tony Lindgren
2005-05-12 16:28 ` Jesse Barnes
2005-05-12 17:12 ` Srivatsa Vaddagiri
2005-05-12 17:59 ` Jesse Barnes
2005-05-12 18:16 ` Tony Lindgren
2005-05-13 6:27 ` Srivatsa Vaddagiri
2005-05-12 18:08 ` Martin Schwidefsky
2005-05-12 18:21 ` Tony Lindgren
2005-05-13 6:23 ` Srivatsa Vaddagiri
2005-05-13 7:16 ` Nick Piggin
2005-05-13 8:04 ` Ingo Molnar [this message]
2005-05-13 8:27 ` Nick Piggin
2005-05-13 9:19 ` Srivatsa Vaddagiri
2005-05-13 9:33 ` Nick Piggin
2005-05-12 21:16 ` George Anzinger
2005-05-12 21:35 ` Jesse Barnes
2005-05-12 22:15 ` George Anzinger
2005-05-13 0:43 ` Jesse Barnes
2005-05-13 6:31 ` Srivatsa Vaddagiri
2005-06-30 12:47 ` Srivatsa Vaddagiri
2005-07-06 17:31 ` Srivatsa Vaddagiri
2005-05-08 10:13 ` [uml-devel] " Arjan van de Ven
2005-05-08 10:13 ` Arjan van de Ven
2005-05-08 13:33 ` [uml-devel] " Andi Kleen
2005-05-08 13:33 ` Andi Kleen
2005-05-08 13:44 ` [uml-devel] " Arjan van de Ven
2005-05-08 13:44 ` Arjan van de Ven
2005-05-08 14:53 ` [uml-devel] " Andi Kleen
2005-05-08 14:53 ` Andi Kleen
2005-05-08 13:31 ` [uml-devel] " Andi Kleen
2005-05-08 13:31 ` Andi Kleen
2005-05-08 15:26 ` [uml-devel] " Srivatsa Vaddagiri
2005-05-08 15:26 ` Srivatsa Vaddagiri
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050513080424.GA31206@elte.hu \
--to=mingo@elte.hu \
--cc=george@mvista.com \
--cc=jdike@addtoit.com \
--cc=jesse.barnes@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nickpiggin@yahoo.com.au \
--cc=rlrevell@joe-job.com \
--cc=schwidefsky@de.ibm.com \
--cc=tony@atomide.com \
--cc=vatsa@in.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.