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]

Message-ID: <000301cb251b$d8cb7bf0$8a6273d0$@org>
Date:	Fri, 16 Jul 2010 13:19:43 -0600
From:	"Ai Li" <aili@...eaurora.org>
To:	"'Arjan van de Ven'" <arjan@...ux.intel.com>
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

> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/