From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Pavel Machek <pavel@ucw.cz>
Cc: "Brown, Len" <len.brown@intel.com>,
Gautham R Shenoy <ego@in.ibm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Rafael J. Wysocki" <rjw@sisk.pl>,
"Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>,
"Li, Shaohua" <shaohua.li@intel.com>, Ingo Molnar <mingo@elte.hu>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"Darrick J. Wong" <djwong@us.ibm.com>
Subject: Re: [PATCH 0/3] cpu: idle state framework for offline CPUs.
Date: Wed, 12 Aug 2009 14:05:43 +0200 [thread overview]
Message-ID: <1250078743.10001.41.camel@twins> (raw)
In-Reply-To: <20090812115806.GK24339@elf.ucw.cz>
On Wed, 2009-08-12 at 13:58 +0200, Pavel Machek wrote:
> Hi!
>
> > May be having (to pick a number) 3 possible offline states for all
> > platforms with one for halt equivalent and one for deepest possible that
> > CPU can handle and one for deepest possible that platform likes for
> > C-states may make sense. Will keeps things simpler in terms of usage
> > expectations and possibly reduce the misuse oppurtubity?
>
> Maybe just going to the deepest offline state automatically is the
> easiest option?
>
> cpu hotplug/unplug should be rare-enough operation that the latencies
> do not really matter, right?
Ha, it uses kstopmachine, anybody caring about hotplug latencies is
insane.
And yeah, I'm not quite sure what this user-interface is good for
either. Having an in-kernel management layer where you can register
various idle routines makes sense. But exposing it to userspace,.. not
so much.
The idle thread can select an idle routine under constraints of the QoS
latency constraints, the unplug loop however should indeed select the
one that is available to dead cpus (not all idle routines are available
from what people tell me), and yields the best power savings.
next prev parent reply other threads:[~2009-08-12 12:11 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-05 14:25 [PATCH 0/3] cpu: idle state framework for offline CPUs Gautham R Shenoy
2009-08-05 14:25 ` [PATCH 1/3] cpu: Offline state Framework Gautham R Shenoy
2009-08-05 14:26 ` [PATCH 2/3] cpu: Implement cpu-offline-state callbacks for pSeries Gautham R Shenoy
2009-08-05 14:26 ` [PATCH 3/3] pSeries: cpu: Cede CPU during a deactivate-offline Gautham R Shenoy
2009-08-06 1:58 ` [PATCH 0/3] cpu: idle state framework for offline CPUs Shaohua Li
2009-08-06 4:33 ` Vaidyanathan Srinivasan
2009-08-06 15:03 ` Peter Zijlstra
2009-08-06 15:13 ` Peter Zijlstra
2009-08-09 12:08 ` Pavel Machek
2009-08-06 13:48 ` Gautham R Shenoy
2009-08-07 1:02 ` Shaohua Li
2009-08-09 12:08 ` Pavel Machek
2009-08-09 13:22 ` Rafael J. Wysocki
2009-08-10 2:00 ` Vaidyanathan Srinivasan
2009-08-10 8:19 ` Pavel Machek
2009-08-11 0:22 ` Pallipadi, Venkatesh
2009-08-11 17:53 ` Dipankar Sarma
2009-08-12 11:58 ` Pavel Machek
2009-08-12 12:05 ` Peter Zijlstra [this message]
2009-08-12 19:57 ` Dipankar Sarma
2009-08-13 0:45 ` Len Brown
2009-08-13 4:59 ` Dipankar Sarma
2009-08-14 11:30 ` Pavel Machek
2009-08-16 18:26 ` Dipankar Sarma
2009-08-16 19:44 ` Balbir Singh
2009-08-16 21:53 ` Peter Zijlstra
2009-08-17 6:24 ` Dipankar Sarma
2009-08-17 7:15 ` Peter Zijlstra
2009-08-17 7:58 ` Dipankar Sarma
2009-08-17 14:40 ` Dipankar Sarma
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=1250078743.10001.41.camel@twins \
--to=a.p.zijlstra@chello.nl \
--cc=djwong@us.ibm.com \
--cc=ego@in.ibm.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mingo@elte.hu \
--cc=pavel@ucw.cz \
--cc=rjw@sisk.pl \
--cc=shaohua.li@intel.com \
--cc=venkatesh.pallipadi@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).