Re: [PATCH] cpufreq_ondemand

[Alexander Clouter <alex-kernel@digriz.org.uk>]

[-- Attachment #1: Type: text/plain, Size: 2044 bytes --]

On Oct 17, Pallipadi, Venkatesh wrote:
> 
> [snipped]
> 
> We can never accurately predict freq for some future load. 
> Say a CPU capable of 600, 800, 1000, 1200 and 1400 KHz, is 
> running at 600 and we have sudden 100% CPU utilization, then 
> we cannot precisely say which should be the next freq. It 
> can be any of the higher possible freqs. And we felt performance 
> should get a higher priority whenever there is some 
> tradeoffs like this.
> 
it took me a while to work out why speed decreasing was 'working' whilst 
speed increasing was not with my method; a good hour finding out that the 
cpufreq (correctly) goes to the lowest match.

My approach was not to try and avoid predicting the desired freq, it was just 
to increase it...well on demand at a steady rate towards 100% and then once 
the load disappears to reduce it.  Having used powernowd and found it do that 
rather nicely, then seeing the inclusion of cpufreq_ondemand, I tweaked 
cpufreq_ondemand to replace powernowd.

I'm all for "this really should be done in userspace", but for something like 
this I have a nagging feeling that its neater in kernel-space.  Of course the 
userspace one has the advantage (I think cpufreqd does it) that you can 
decide if you want to increase the freq depending on what applications are 
running.

Of course you are using CPU cycles, though bearly any, to have this floating 
requested_freq variable.  Of course I would love this to be in the kernel, 
mainly though I wanted people to improve upon it and such.

Meanwhile I am thinking of moving that freq_step variable bits to the /sys 
show/store functions to remove a avoidable divide.

Cheers

Alex

-- 
 ____________________________________ 
/ Let your conscience be your guide. \
|                                    |
\ -- Pope                            /
 ------------------------------------ 
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]