lkml.org 
[lkml]   [2009]   [Dec]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [v10 PATCH 2/9]: cpuidle: cleanup drivers/cpuidle/cpuidle.c
* Torsten Duwe <duwe@lst.de> [2009-12-04 23:20:00]:

> On Wednesday 02 December 2009, Arun R Bharadwaj wrote:
> > * Arun R Bharadwaj <arun@linux.vnet.ibm.com> [2009-12-02 15:24:27]:
> >
> > This patch cleans up drivers/cpuidle/cpuidle.c
> > Earlier cpuidle assumed pm_idle as the default idle loop. Break that
> > assumption and make it more generic.
>
> Is there a problem with the old pm_idle? Couldn't it be integrated more
> transparently, instead of replacing it this intrusively?
>

Hi Torsten,

Peter objected to the idea of integrating this with the old pm_idle
because it has already caused a lot of problems on x86 and we wouldn't
want to be doing the same mistake on POWER. The discussion related to
that could be found here http://lkml.org/lkml/2009/8/26/233

> > --- linux.trees.git.orig/include/linux/cpuidle.h
> > +++ linux.trees.git/include/linux/cpuidle.h
> > @@ -41,7 +41,7 @@ struct cpuidle_state {
> > unsigned long long usage;
> > unsigned long long time; /* in US */
> >
> > - int (*enter) (struct cpuidle_device *dev,
> > + void (*enter) (struct cpuidle_device *dev,
> > struct cpuidle_state *state);
> > };
>
> While it may be a good idea to move the residency calculation to one central
> place, at least in theory a cpuidle_state->enter() function could have a
> better method to determine its value.
>

This would mean a lot of code replication, which Pavel pointed out in
the previous iteration. So I moved the residency calculation to a
central place.

> Either way you're implicitly introducing an API change here, and you're at
> least missing two functions on ARM and SuperH, respectively. Could you
> separate this API change out, and not take it for granted in the other
> patches?
>
> Torsten


\
 
 \ /
  Last update: 2009-12-06 06:23    [W:0.138 / U:0.272 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site