Messages in this thread | | | From | "Ai Li" <> | Subject | RE: [PATCH] cpuidle: extend cpuidle and menu governor to handle dynamic states | Date | Fri, 16 Jul 2010 13:52:32 -0600 |
| |
> 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%".
| |