linux-kernel - Re: [PATCH] cpuidle: extend cpuidle and menu governor to handle dynamic states

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 16 Jul 2010 12:33:10 -0700
From:	Arjan van de Ven <arjan@...ux.intel.com>
To:	Ai Li <aili@...eaurora.org>
CC:	akpm@...ux-foundation.org, dwalker@...eaurora.org, mingo@...e.hu,
	shemminger@...tta.com, czoccolo@...il.com, len.brown@...el.com,
	linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
	linux-pm@...ts.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/