[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1254921857.26976.249.camel@twins>
Date: Wed, 07 Oct 2009 15:24:17 +0200
From: Peter Zijlstra <a.p.zijlstra@...llo.nl>
To: balbir@...ux.vnet.ibm.com
Cc: Vaidyanathan Srinivasan <svaidy@...ux.vnet.ibm.com>,
Arjan van de Ven <arjan@...radead.org>,
arun@...ux.vnet.ibm.com, Joel Schopp <jschopp@...tin.ibm.com>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Paul Mackerras <paulus@...ba.org>, Ingo Molnar <mingo@...e.hu>,
Dipankar Sarma <dipankar@...ibm.com>,
Gautham R Shenoy <ego@...ibm.com>,
Venkatesh Pallipadi <venkatesh.pallipadi@...el.com>,
linux-kernel@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
linux-arch@...r.kernel.org
Subject: Re: [v7 PATCH 0/7]: cpuidle/x86/POWER: Cleanup idle power
management code in x86, cleanup drivers/cpuidle/cpuidle.c and introduce
cpuidle to POWER.
On Wed, 2009-10-07 at 17:17 +0530, Balbir Singh wrote:
> > The objective of the refactoring is to have a single common idle
> > routine management framework (remove pm_idle) and we have it done
> > through cpuidle registration framework. We can incrementally remove
> > the per-cpu registration later easily by splitting the cpuidle_driver
> > structure.
> >
>
> Yes, incremental refactoring makes the most sense from the do not
> break as you refactor point of view.
Sure,.. but I would have though getting rid of the per-cpu-ish-ness
would have made the latter patches in this series easier. But maybe I'm
lazy ;-)
Let me go over the patches one more time, but they do look ok.
--
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