cpuidle: extend cpuidle and menu governor to handle dynamic states
in [Kernel]
|
From: Ai Li on 16 Jul 2010 13:30 > > + if (dev->prepare) > > + dev->prepare(dev, data->predicted_us); > > > > I don't like the idea of passing predicted_us here. > the states and their updates should be independent of how long we > think we'll be idle; The power_usage value, total or average, would depend on how long the predicted idle period is. On our SoCs, a cpuidle state has three stages: entry stage, low power stage, and exit stage. Entry and exit stages consume more power than the low power stage but have fixed durations, irrespective how long the idle period is. As the predicted idle period changes, the entry and exit duration stay the same but the low power duration changes, resulting in different total or average power for the idle period. > Also I would like the cpuidle code, not the governor, to call this > prepare function. > The need to call ->prepare is governor independent.... I agree that it would be cleaner to call ->prepare from the cpuidle code. But if we need values calculated in the governor's select function, I'm not sure what is the best way to do that from cpuidle code. > + if (dev->compare_power) { > > I'm not a big fan of this as a flag; either we always do this, > which I > can understand, or we sort things, which is also fine with me. > Doing this condition like this.... not a fan. One of the concerns I have is backwards compatibility. As far as I know, none of the current cpuidle drivers use the power_usage field. If we always do compare_power, those drivers would break until someone with technical device knowledge update the drivers to specify power... I could derive fake power_usage numbers by default, using the cstate index position. That seems kind of hacky but it would remove the need for the compare_power flag and retain the current behavior when cpuidle drivers do not provide their own power numbers. ~Ai Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ai Li on 16 Jul 2010 15:30 > 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. > > One of the concerns I have is backwards compatibility. As far as > I > > know, none of the current cpuidle drivers use the power_usage > field. > > If we always do compare_power, those drivers would break until > > someone with technical device knowledge update the drivers to > specify > > power... I could derive fake power_usage numbers by default, > using > > the cstate index position. That seems kind of hacky but it would > > remove the need for the compare_power flag and retain the current > > behavior when cpuidle drivers do not provide their own power > numbers. > > > > I'm fine with this approach actually; if someone does not fill it > in, we fake data that makes it > valid... better than getting complex code. OK. ~Ai Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ai Li on 16 Jul 2010 16:00 > 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(a)linux.intel.com] > Sent: Friday, July 16, 2010 1:33 PM > To: Ai Li > Cc: akpm(a)linux-foundation.org; dwalker(a)codeaurora.org; > mingo(a)elte.hu; shemminger(a)vyatta.com; czoccolo(a)gmail.com; > len.brown(a)intel.com; linux-kernel(a)vger.kernel.org; linux-arm- > msm(a)vger.kernel.org; linux-pm(a)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%". -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|
Pages: 1 Prev: [PATCH] rt2x00: Fix lockdep warning in rt2x00lib_probe_dev() Next: [GIT PULL] perf fixes |