From: Trinabh Gupta <trinabh@linux.vnet.ibm.com>
To: Len Brown <lenb@kernel.org>
Cc: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>,
arjan@linux.intel.com, Stephen Rothwell <sfr@canb.auug.org.au>,
peterz@infradead.org, suresh.b.siddha@intel.com,
benh@kernel.crashing.org, venki@google.com, ak@linux.intel.com,
linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com
Subject: Re: cpuidle asymmetry (was Re: [RFC PATCH V4 5/5] cpuidle: cpuidle driver for apm)
Date: Fri, 01 Apr 2011 12:32:01 +0530 [thread overview]
Message-ID: <4D957869.3050607@linux.vnet.ibm.com> (raw)
In-Reply-To: <alpine.LFD.2.02.1103302203490.1920@x980>
On 03/31/2011 07:47 AM, Len Brown wrote:
>>>> Maybe there is some other way to handle asymmetry ??
>
> I mis-spoke on asymmetry.
>
> Moorestown is already an example of an asymmetric system,
> since its deepest c-state is available on cpu0, but not on cpu1.
> So it needs different tables for each cpu.
>
> I think what would work is a default c-state table for the system,
> and the ability of a per-cpu override table. I think that would
> gracefully handle the case of many identical cpus, and also systems
> with different tables per cpu.
Hi Len,
What would happen if a cpu enters a state which wasn't
reported for it? I am wondering if an approach like union
of states of each would work.
Can we handle asymmetry through checking and demotion inside the
routine itself; just like you are proposing as dev->prepare
alternative? But I guess this may not be efficient if this
happens often.
I am not sure if having a per-cpu override would be very tidy
(ideas ?); and much better than per-cpu stuff. So just want to check
what would be the best way forward?
>
> The same goes for write-access to the tables.
> In the typical case, a single table can be shared for the entire system
> and nobody will be writing to it. However, with the governor changes
> to call dev->prepare and sift through all the states to find the
> legal one with the lowest power_usage... There is software today
> out of tree that updates that power_usage entry from prepare().
>
> As I mentioned, I'm not fond of that mechanism - it looks racey
> to me. I'd rather see the capability of a drivers idle handler
> to demote to another handler in the driver and for the accounting
> to not get messed up when that happens. I think the way to do that
> is to let the driver do the accounting rather than doing it in
> the cpuidle caller.
I agree with this; we should move update of statistics inside the
driver routines (enter routines). They already take device/stats
structure as parameter.
Thanks,
-Trinabh
prev parent reply other threads:[~2011-04-01 7:02 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20110322123208.28725.30945.stgit@tringupt.in.ibm.com>
[not found] ` <20110322123324.28725.3131.stgit@tringupt.in.ibm.com>
2011-03-22 14:50 ` [RFC PATCH V4 4/5] cpuidle: driver for xen Konrad Rzeszutek Wilk
2011-03-23 9:57 ` Trinabh Gupta
2011-03-24 7:18 ` Len Brown
2011-03-24 12:05 ` Konrad Rzeszutek Wilk
2011-03-25 7:19 ` Len Brown
2011-03-25 14:43 ` Jeremy Fitzhardinge
2011-03-25 14:38 ` [Xen-devel] " Jeremy Fitzhardinge
2011-03-31 2:02 ` Len Brown
2011-03-31 21:26 ` Len Brown
2011-03-31 22:36 ` [Xen-devel] " Jeremy Fitzhardinge
2011-04-01 3:03 ` Len Brown
[not found] ` <20110322123233.28725.92874.stgit@tringupt.in.ibm.com>
[not found] ` <alpine.LFD.2.02.1103222254420.10549@x980>
2011-03-23 9:22 ` [RFC PATCH V4 2/5] cpuidle: list based cpuidle driver registration and selection Trinabh Gupta
2011-03-23 20:51 ` Len Brown
2011-03-24 4:41 ` Len Brown
2011-03-24 14:13 ` Trinabh Gupta
2011-03-24 16:52 ` Vaidyanathan Srinivasan
2011-03-25 7:13 ` Len Brown
2011-03-25 7:05 ` Len Brown
2011-03-25 15:35 ` [Xen-devel] " Konrad Rzeszutek Wilk
2011-03-31 2:25 ` Len Brown
[not found] ` <20110322123244.28725.32435.stgit@tringupt.in.ibm.com>
[not found] ` <alpine.LFD.2.02.1103222304300.10549@x980>
2011-03-23 9:31 ` [RFC PATCH V4 3/5] cpuidle: default idle driver for x86 Trinabh Gupta
2011-03-24 16:32 ` Vaidyanathan Srinivasan
[not found] ` <20110322123223.28725.21929.stgit@tringupt.in.ibm.com>
[not found] ` <20110323120044.bb8c0ae1.sfr@canb.auug.org.au>
2011-03-23 10:10 ` [RFC PATCH V4 1/5] cpuidle: Remove pm_idle pointer " Trinabh Gupta
[not found] ` <20110322123336.28725.29810.stgit@tringupt.in.ibm.com>
[not found] ` <20110323121458.ec7cdaf9.sfr@canb.auug.org.au>
2011-03-23 10:25 ` [RFC PATCH V4 5/5] cpuidle: cpuidle driver for apm Trinabh Gupta
2011-03-23 20:32 ` Len Brown
2011-03-24 14:28 ` Trinabh Gupta
2011-03-24 16:21 ` Vaidyanathan Srinivasan
2011-03-25 7:24 ` Len Brown
2011-03-25 18:01 ` Vaidyanathan Srinivasan
2011-03-31 2:17 ` cpuidle asymmetry (was Re: [RFC PATCH V4 5/5] cpuidle: cpuidle driver for apm) Len Brown
2011-03-31 13:18 ` Peter Zijlstra
2011-04-01 4:09 ` Len Brown
2011-04-01 8:15 ` Dipankar Sarma
2011-04-01 14:38 ` Arjan van de Ven
2011-04-03 16:18 ` Dipankar Sarma
2011-04-01 14:02 ` Peter Zijlstra
2011-04-04 14:32 ` Dipankar Sarma
2011-04-05 15:01 ` Peter Zijlstra
2011-04-05 15:48 ` Dipankar Sarma
2011-04-01 7:02 ` Trinabh Gupta [this message]
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=4D957869.3050607@linux.vnet.ibm.com \
--to=trinabh@linux.vnet.ibm.com \
--cc=ak@linux.intel.com \
--cc=arjan@linux.intel.com \
--cc=benh@kernel.crashing.org \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=sfr@canb.auug.org.au \
--cc=suresh.b.siddha@intel.com \
--cc=svaidy@linux.vnet.ibm.com \
--cc=venki@google.com \
--cc=xen-devel@lists.xensource.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).