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

From: Arjan van de Ven
Date: Fri Jul 16 2010 - 15:33:20 EST


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%".

--
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/