RFC: powerd algorithms enhancements

[Alexander Motin]

Ian Smith wrote:
> Thanks; I've had a brief browse only so far, but like the approach.  
> Not sure where you get these 7/8 and 31/32 factors from, and I've no 

Just empirical. It's just a nice numbers which seem to give good enough 
results.

> hardware to test with lots of freqs, but I'm interested to see how 
> things like hysteresis under constant but partial load operate (ie 
> avoiding too much 'hunting' as freq change varies measured load ..)

If you will look closer, you will see that there is actually even two 
hysteresis present. First is the original "idle"/"running" planks. And 
the second one is the special check on reducing frequency that verifies 
that estimated load at lower frequency will be less then "running" plank.

>  > >  > 2. To make powerd's operation independent from number and size of frequency
>  > >  > levels I have added internal frequency counter which translated into real
>  > >  > frequencies only on a last stage and only as good as gone. Some systems may
>  > >  > have only several power levels, while mine has 17 of them, so adaptation time
>  > >  > in completely different. It would be good if algorithm was not depending on
>  > >  > it.
> 
> Just for reference, could you show the levels you're working with?

dev.cpu.0.freq_levels: 2400/35000 2100/30625 2000/28000 1750/24500 
1600/22000 1400/19250 1200/16000 1050/14000 900/12000 800/14000 
700/12250 600/10500 500/8750 400/7000 300/5250 200/3500 100/1750

>  > >  > 3. As part of previous I have changed adaptive mode to rise frequency on
>  > >  > demand up to 2 times and fall on 1/8 per time internal.
>  > > 
>  > > I'm wondering how the edge case with only 2 freqs would go?  Eg on my 
>  > > T23, single cpu P3 Mobile at 1133 and 733MHz.  That is, I'm wondering if 
>  > > your 1/8 factor might better be scaled to no. of cpus and/or no. of 
>  > > freqs available?  I'd best say no more until studying your algorithm ..
>  > 
>  > I have not such case, but I think there should be no problem.
> 
> Ok .. just to confirm I'm reading it right: you wind up using the first 
> table freq BELOW the calculated desired freq, right?  So with my case of 
> 1133 & 733, if at 1133 and coming down, 7/8 * 1133 = 991, so select 733?

No. I am using frequency equal or above to desired. So ad 991 I will 
still select 1133. 733 will be set only after 4 steps:
1133*7/8 => 991
991*7/8 => 867
867*7/8 => 758
758*7/8 => 733

>  > Move configuration from command line into configuration file will allow
>  > more customized profiles to be written, so if somebody wants to - he may
>  > do it. For trivial command line configuration this solution looks like
>  > appropriate.
> 
> Sure.  I do want to get to that, though C is mostly read-only for me, 
> and there's still way too much I know way too little about :) but with 
> modern laptops it's clear that just telling people to enable powerd 
> isn't cutting it anymore, especially with the sort of issues people are 
> seeing with systems dropping back to ridiculously low cpu freqs - like 
> perhaps the default cpufreq.lowest ought to be initially set no lower 
> than perhaps 1/8 of full speed, out of the box, to mitigate such issues?

Huge latency on low frequencies was actually that reason why I have 
started this work. Now with new exponential algorithms and reduced 
polling interval I am no longer experiencing any problems.

Defining minimal CPU frequency is a completely wrong way IMO as it will 
not allow to really use all power management abilities. The main goal of 
the exponential frequency reducing, which I have implemented, was to 
increase time interval before setting lowest frequency. In my case, 
while working at 2400MHz, powerd will drop 300MHz per single 1/4s 
interval, but it will take 1.5s of completely idle CPU to drop from 
200MHz to 100MHz on batteries and 5s on AC-power!

-- 
Alexander Motin