[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1302015692.2225.1347.camel@twins>
Date: Tue, 05 Apr 2011 17:01:32 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: dipankar@...ibm.com
Cc: Len Brown <lenb@...nel.org>,
Vaidyanathan Srinivasan <svaidy@...ux.vnet.ibm.com>,
Trinabh Gupta <trinabh@...ux.vnet.ibm.com>,
arjan@...ux.intel.com, Stephen Rothwell <sfr@...b.auug.org.au>,
suresh.b.siddha@...el.com, benh@...nel.crashing.org,
venki@...gle.com, ak@...ux.intel.com, linux-kernel@...r.kernel.org,
xen-devel@...ts.xensource.com
Subject: Re: cpuidle asymmetry (was Re: [RFC PATCH V4 5/5] cpuidle: cpuidle
driver for apm)
On Mon, 2011-04-04 at 20:02 +0530, Dipankar Sarma wrote:
> On Fri, Apr 01, 2011 at 04:02:36PM +0200, Peter Zijlstra wrote:
> >
> > > S0i3 on cpu0 can be entered only after cpu1 is already off-line,
> > > among other system hardware dependencies...
> > >
> > > So it makes no sense to export S0i3 as a c-state on cpu1.
> > >
> > > When cpu1 is online, the scheduler treats it as a normal SMP.
> >
> > Dipankar's reply seems to address this issue well.
>
> I can't find any Moorestown documentation at the Intel site, but
> thinking about Len's inputs a bit more, it seems there may
> be still a problem asymetry from the scheduler perspective.
>
> If cpu0 or cpu1 either of them can be offlined, there is no
> asymetry. If only cpu1 can be offlined, it would mean that
> one cpu may be more efficient depending on how we do
> cpu offlining for power savings. It gets a bit messy.
>
> Len, what exacty is the significance of offlining here ?
> Apart from going to C6, what else is needed in cpu1 for
> the chip to go to S0i3 ? Why is idle C6 not enough ?
I don't think offlining is relevant, anybody using that for power
management is doing it wrong, _very_ wrong.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists