Messages in this thread | | | Date | Mon, 18 Oct 2004 09:39:05 +0100 | From | Alexander Clouter <> | Subject | Re: [PATCH] cpufreq_ondemand |
| |
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 | || || [unhandled content-type:application/pgp-signature] | |