# powerd wants to set too high max speed of CPU



## Markus Witt (Sep 3, 2015)

Hi,

I need some help. powerd(8) want to step to a too high CPU speed and so the freq step down starts always from a high frequency and needs too long to reach the lower level after every peek.

Why want powerd(8) set the CPU freq to 3000MHz, the CPU supports only 1500MHz and why a load over 100% (sum of the load from all cores)?

Here are some outputs:

```
dmesg -> CPU: AMD A4-5000 APU with Radeon(TM) HD Graphics  (1497.22-MHz K8-class CPU)
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
```


```
sysctl dev.cpu.0.freq_levels: 1500/2184 1300/1950 1100/1660 950/1441 800/1187
```


```
powerd -v
..
load  65%, current freq 1500 MHz ( 0), wanted freq 1386 MHz
load 107%, current freq 1500 MHz ( 0), wanted freq 3000 MHz
load 116%, current freq 1500 MHz ( 0), wanted freq 3000 MHz
load  4%, current freq 1500 MHz ( 0), wanted freq 2906 MHz
...
load  25%, current freq 1500 MHz ( 0), wanted freq 1350 MHz
load  0%, current freq 1500 MHz ( 0), wanted freq 1307 MHz
load  22%, current freq 1500 MHz ( 0), wanted freq 1266 MHz
changing clock speed from 1500 MHz to 1300 MHz
load 104%, current freq 1300 MHz ( 1), wanted freq 3000 MHz
```
Thanks, markus


----------



## wblock@ (Sep 3, 2015)

powerd(8) is predictive and determines the desired CPU speed based on load.  So yes, it can "want" a CPU frequency that is higher than actually available.  It will only get what is available, of course.

There are four built-in profiles that can be selected, along with several options to control how power(8) acts.  One or more of those might make it act more like you expect or want.


----------



## Markus Witt (Sep 3, 2015)

Thanks with adaptive mode it works.
I had to use the `-n adaptive` option (I was thinking this is default...didn't read the man very well) .
Bad that I can't set the max "want" CPU freq for hiadaptive, so this mode make no sense for me.


----------



## mav@ (Sep 3, 2015)

Twice higher values in hiadaptive mode is a way to delay frequency drop after large load spike. hiadaptive profile is oriented on high-performance AC-powered systems, where performance is more important than power usage. If in your case frequency does not drop, then your system is not very idle according to this profile.


----------



## Terry_Kennedy (Sep 7, 2015)

Markus Witt said:


> ...why a load over 100% (sum of the load from all cores)?


Just to address this part of your question, yes. Take a look at the attached output from `# top -S`. The summary line says the system is 99.9% idle, but the idle process accounts for 1199.51% of the CPU (this is a system with 12 cores and hyperthreading disabled).


```
last pid: 53208;  load averages:  0.16,  0.13,  0.09   up 34+20:07:59  19:37:08
135 processes: 2 running, 131 sleeping, 1 waiting
CPU:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt, 99.9% idle
Mem: 1332M Active, 8613M Inact, 5132M Wired, 35M Cache, 4923M Buf, 32G Free
Swap: 32G Total, 32G Free

  PID USERNAME     THR PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
   11 root          12 171 ki31     0K   192K CPU0    0 9945.2 1199.51% idle
   ...
```


----------



## User7 (Sep 18, 2015)

Try in /etc/rc.conf add:
`powerd_enable="YES"` and `powerd_flags="-b min -a hiadaptive` when you use battery powerd set lowest avalaible value, and when be used AC were will be adaptive. Or try to use cpufreq.


----------



## aragats (Feb 4, 2016)

The problem is that you can't set powerd(8)'s percentage flags to more than 100%. Taking into account the fact that multicore/multithread CPUs report significantly higher values, you may want it.

In other words, in such cases even 
	
	



```
powerd -r 100 ...
```
 causes the frequency to jump to the max even with a moderate load of the CPU. It's not good especially for laptops which get hot without reason.


----------



## mav@ (Feb 4, 2016)

Setting there value above 100% could lead to suboptimal performance, when single CPU core is busy but can not run at full frequency.


----------



## aragats (Feb 4, 2016)

My point is that powerd(8) could have an option either to set percentage values higher than 100% or an option to scale them based on the number of CPU cores.
Here is a real example: my 4 core CPU supports frequencies in range of 1200...2900MHz. When it's in a semi-idle state (browsing with Firefox), powerd(8) keeps it at 1200MHz, as soon as I turn on a youtube video the CPU usage jumps to 115%, and powerd(8) switches the frequency to 2900Mhz, which is definitely unneeded. When I encode video with ffmpeg the CPU usage is close to 400% (4 cores combined), the frequency is 2900Mhz, which is reasonable.


----------



## mav@ (Feb 4, 2016)

I understand your point. But my point is that you want wrong thing. Many applications, and possibly video decoding too, have limited SMP scalability. 115% of CPU load may mean one CPU core busy by 100%, plus one more by 15%.  If in that situation you drop frequency twice -- you just drop your frame rate twice, while hardly save much power.  And my point is that you don't want it.


----------



## aragats (Feb 4, 2016)

Agree, it's a good point. However, in theory it is possible to control frequency per core for some CPUs, but practically it's definitely not a job for powerd(8).


----------



## mav@ (Feb 4, 2016)

AFAIK it is typically possible to control frequency by package. In some rare cases (like Pentium D or Core2Quad) -- by half of package. But that level of control requires tight scheduler integration. Otherwise scheduler may schedule threads to packages running at lowest speed, killing performance again.

I think the most realistic way to scale power consumption of many-core systems is BIG.little scheme used by some ARM CPUs. Since we don't have cores with different power consumption on x86, it could mean just putting some cores/packages into deepest possible sleep to conserve power if load does not need them.  With C-states enabled now by default idle CPU cores are going to some sleep, but without strict power policy applied to that scheduler may wake them up any time, so power saving suffers.


----------

