Re: [PATCH] cpuidle: extend cpuidle and menu governor to handle dynamicstates

[Arjan van de Ven]

On 7/16/2010 10:25 AM, Ai Li wrote:
> > > +	if (dev->prepare)
> > > +		dev->prepare(dev, data->predicted_us);
> > >
> > >        
> > I don't like the idea of passing predicted_us here.
> > the states and their updates should be independent of how long we
> > think we'll be idle;
> >      
> The power_usage value, total or average, would depend on how long the
> predicted idle period is.  On our SoCs, a cpuidle state has three
> stages: entry stage, low power stage, and exit stage.  Entry and exit
> stages consume more power than the low power stage but have fixed
> durations, irrespective how long the idle period is.  As the
> predicted idle period changes, the entry and exit duration stay the
> same but the low power duration changes, resulting in different total
> or average power for the idle period.
>    

the power value in the structure should represent ONLY the power level 
during the low power stage.
And this should be independent of total duration.

all other power is taken into account in terms of break even point/etc...


> One of the concerns I have is backwards compatibility.  As far as I
> know, none of the current cpuidle drivers use the power_usage field.
> If we always do compare_power, those drivers would break until
> someone with technical device knowledge update the drivers to specify
> power...  I could derive fake power_usage numbers by default, using
> the cstate index position.  That seems kind of hacky but it would
> remove the need for the compare_power flag and retain the current
> behavior when cpuidle drivers do not provide their own power numbers.
>    

I'm fine with this approach actually; if someone does not fill it in, we 
fake data that makes it
valid... better than getting complex code.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/