choice of absolute / relative freqs with est + p4tcc

Ian Smith smithi at nimnet.asn.au
Wed Jan 16 05:41:37 PST 2008


On Wed, 16 Jan 2008, Tijl Coosemans wrote:
 > On Wednesday 16 January 2008 05:29:47 Ian Smith wrote:
 [..]
 > > dev.cpu.0.freq_levels: 1200/-1 1100/-1 1000/-1 900/-1 800/-1 700/-1 600/-1 525/-1 450/-1 375/-1 300/-1 225/-1 150/-1 75/-1

 > > dev.est.0.freq_settings: 1200/-1 1100/-1 1000/-1 900/-1 800/-1 600/-1

 > > dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1
 > > 
 > > .. and find myself curious why 550 (1100 * .5) and 500 (1000 * .5)
 > > would not be chosen when 525 (600 * .875) was, going by the comments:
 > > 
 > > 	/*
 > > 	 * Walk the set of all existing levels in reverse.  This is so we
 > > 	 * create derived states from the lowest absolute settings first
 > > 	 * and discard duplicates created from higher absolute settings.
 > > 	 * For instance, a level of 50 Mhz derived from 100 Mhz + 50% is
 > > 	 * preferable to 200 Mhz + 25% because absolute settings are more
 > > 	 * efficient since they often change the voltage as well.
 > > 	 */
 > > and 
 > > 	/*
 > > 	 * Insert the new level in sorted order.  If it is a duplicate of an
 > > 	 * existing level (1) or has an absolute setting higher than the
 > > 	 * existing level (2), do not add it.  We can do this since any such
 > > 	 * level is guaranteed use less power.  For example (1), a level with
 > > 	 * one absolute setting of 800 Mhz uses less power than one composed
 > > 	 * of an absolute setting of 1600 Mhz and a relative setting at 50%.
 > > 	 * Also for example (2), a level of 800 Mhz/75% is preferable to
 > > 	 * 1600 Mhz/25% even though the latter has a lower total frequency.
 > > 	 */
 > 
 > It's because of (2) in the second comment. 550 and 500 likely use more
 > power than 600 and 525, so it doesn't make sense to use them.

Ah, ok, thanks.

I hadn't really grokked (2) as it compares 600 with 400MHz, which seemed
'obviously' preferable, but for the wrong reason .. pardon the noise.

cheers, Ian



More information about the freebsd-acpi mailing list