RE: [PATCH] cpuidle: extend cpuidle and menu governor to handle dynamic states

["Ai Li" <aili@codeaurora.org>]

> that's nice in theory.
> in practice though, this is all noise compared to some of the
> accuracy in the predictions.
> 
> break even generally is done against C1 only (since C1 is assumed
> to always be there)....
> yes it'd be nice to also have it against Cx in a matrix form, but
> that is a level of complexity that
> hasn't been worth it.
> 
> Note that the prediction is.... a prediction. I can show you data
> on how well it does (now that it's
> much better in 2.6.35-rc), but it's still "50% of the time we're
> within a factor of two of actual".
> not "we're 90% of the time within 10%".

OK.  I guess we can always add something like predicted_us later,
especially when the predication is more accurate.  For this patch, I
will change to
int (*prepare) (struct cpuidle_device *dev), and call it in cpuidle
instead of the govenor.

~Ai

Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum


> -----Original Message-----
> From: Arjan van de Ven [mailto:arjan@linux.intel.com]
> Sent: Friday, July 16, 2010 1:33 PM
> To: Ai Li
> Cc: akpm@linux-foundation.org; dwalker@codeaurora.org;
> mingo@elte.hu; shemminger@vyatta.com; czoccolo@gmail.com;
> len.brown@intel.com; linux-kernel@vger.kernel.org; linux-arm-
> msm@vger.kernel.org; linux-pm@lists.linux-foundation.org
> Subject: Re: [PATCH] cpuidle: extend cpuidle and menu governor to
> handle dynamic states
> 
> On 7/16/2010 12:19 PM, Ai Li wrote:
> >> 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...
> >>
> > With static cstates, determining the break even point is
> > straitforward, compare the power numbers of state Cn and Cn-1,
> since
> > the states are ordered in increasing order of latency and power.
> > With dynamic cstates, Cn-1 may not be a valid state to compare
> any
> > more, for example, because Cn-1's latency may have become too
> high.
> > It seems the driver would need to know which cstate the govenor
> would
> > compare Cn to, and that would break the design philosophy of
> driver +
> > govenor.  The break even point does not seem to have a
> transistive
> > property, where the govenor can calculat Cn vs Cn-2 from some
> > arithmatic combination of Cn vs Cn-1 and Cn-1 vs Cn-2 values.  On
> the
> > other hand, if the power_usage field also includes the entry and
> exit
> > stages, then the driver does not need to know whether it should
> > calculate break even point for Cn vs Cn-1, or Cn vs Cn-2, etc.
> >
> 
> that's nice in theory.
> in practice though, this is all noise compared to some of the
> accuracy
> in the predictions.
> 
> break even generally is done against C1 only (since C1 is assumed
> to
> always be there)....
> yes it'd be nice to also have it against Cx in a matrix form, but
> that
> is a level of complexity that
> hasn't been worth it.
> 
> Note that the prediction is.... a prediction. I can show you data
> on how
> well it does (now that it's
> much better in 2.6.35-rc), but it's still "50% of the time we're
> within
> a factor of two of actual".
> not "we're 90% of the time within 10%".