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
