> 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@xxxxxxxxxxxxxxx] > Sent: Friday, July 16, 2010 1:33 PM > To: Ai Li > Cc: akpm@xxxxxxxxxxxxxxxxxxxx; dwalker@xxxxxxxxxxxxxx; > mingo@xxxxxxx; shemminger@xxxxxxxxxx; czoccolo@xxxxxxxxx; > len.brown@xxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; linux-arm- > msm@xxxxxxxxxxxxxxx; linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx > 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%". _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
