Bug 131473

Summary: powerd(8) is not responsive enough for Intel CPUs with many CPU speed-steps
Product: Base System Reporter: Naoyuki Tai <ntai>
Component: kernAssignee: freebsd-acpi (Nobody) <acpi>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: 7.1-RELEASE   
Hardware: Any   
OS: Any   

Description Naoyuki Tai 2009-02-07 20:10:05 UTC
I have a machine with following freq_levels.

dev.cpu.0.freq_levels: 1733/27000 1516/23625 1333/21000 1166/18375 1067/17000 933/14875 800/13000 700/11375 600/9750 500/8125 400/6500 300/4875 200/3250 100/1625

There are 14 levels. powerd pushes up 2 levels at a time, and comes down 1 at a time. This makes the machine quite sluggish for many of interactive/event driven applications. Also, coming down is unnecessary long.

In short, when there are many freq_levels, bumping up the speed needs to take the number of levels into account.
If the step-up steps are too large, the machine eats unnecessary power, as the CPU speed goes up too fast, so the balance should be considered, but fixed 2 steps seems is too limited for the machine with many freq_levels.

Perhaps, the right approach is to let you choose how much latency you'd expect for the CPU to get to the maximum speed. For example, you you say 300ms to get to the max CPU speed, you need to jump up the third of freq_levels for every 100ms.

Fix: 

To make the speed-up propotional to the number of levels, step-up steps to be derived from the number of available CPU frequencies.
I changed the powerd.c as follows. This makes the CPU full speped in 4*100ms, instead of 7*100ms. (14/3 = 4 so it needs max of 4 iterations of powerd to get full speed.)

nile# diff powerd.c.orig powerd.c
588c588
< 		 * If we're idle less than the active mark, bump up two levels.
---
> 		 * If we're idle less than the active mark, bump up a few levels.
597c597,599
< 			i -= 2;
---
> 			int steps = (numfreqs / 3);
> 			if (steps < 2) steps = 2;
> 			i -= steps;
How-To-Repeat: Do any user interaction, or run a database, web server etc that takes any user interaction.
Comment 1 Gavin Atkinson freebsd_committer freebsd_triage 2009-02-10 13:57:25 UTC
Responsible Changed
From-To: freebsd-i386->freebsd-acpi

Although not strictly acpi-related, this seems to be where most 
of the work on powerd(1) takes place.  Over to interested parties.
Comment 2 Alexander Motin freebsd_committer freebsd_triage 2009-02-10 18:14:47 UTC
State Changed
From-To: open->closed

This is duplicate PR. The problem already fixed in 7-STABLE.