Messages in this thread | | | Date | Tue, 19 Oct 2004 00:18:18 +0100 | From | Alexander Clouter <> | Subject | Re: [PATCH] cpufreq_ondemand |
| |
On Oct 18, Pallipadi, Venkatesh wrote: > > >The improvements (well I think they are) I have made: > > > >1. I have replaced the algoritm it used to one which > >calculates the number of > > cpu idle cycles that have passed and compares it to the > >number of cpu > > cycles it would have expected to pass (for, the > >defaults, 20%/80%) > > > > this means a couple of divisions have been removed, > >which is always > > nice and it lead to clearer code (for me at least), that was > > until I added the handful of 'if' conditionals though.... :-/ > > > Good idea. This part of the patch has to go into ondemand governor. > What I will do over the next few days is split up the patch to little bits (seems to keep the kernel gods happier, cannot say I blame them) and then post that for you all to pull apart and mull over?
> But, I think there is a minor bug in the code though. > With current ondemand governor, we poll at some X freq and check > whether we need to increase the freq. And with some Y freq (Y > X and > a multiple of it), we check whether we need to decrase the freq. > That is the reason I have two different variables > prev_cpu_idle_down and prev_cpu_idle_up to store the previous idle > times at these two different polling intervals (X and Y). > Now, you have previous idle time at only one point. So, this may > not work cleanly. From the code I feel what will happen is > You will only see the CPU activity in last X time and decide on > frequency down decisions (even though you check this with Y polling > interval). Not sure whether I was clear with this explanation. > My code records the number of both the total idle ticks and the overall ticks at the last interval. This means if I subtract those values for the ones at the next interval I can work out what the 'cpu use' is over that period thats just passed by looking at the percentage difference between (total-idle) and if it trips the expected values if an increase or decrease in frequency was needed.
This is really the main reason why the polling interval has to be decreased by a large amount (I make it occur 50 times fewer times) so the period does not get skewed by *very* brief cpu spikes.
> Note, I haven't really run your version yet. This is what > I feel by looking at the patch. I may well be wrong. > Well in the fashion of the netfilter folk, "Works for Me(tm)" :) Sitting there with 'watch' on /sys/.../ondemand/requested_freq seems to return perfectly sane results.
> > 2. controllable through > > /sys/.../ondemand/ignore_nice, you can tell it to > >consider 'nice' > > time as also idle cpu cycles. Set it to '1' to treat > >'nice' as cpu > > in an active state. > > > > OK. This has to be in ondemand governor as well. > I'll split this out as I think it should be in there.
> >3. (major) the scaling up and down of the cpufreq is now > >smoother. I found > > it really nasty that if it tripped < 20% idle time that > >the freq was > > set to 100%. This code smoothly increases the cpufreq > >as well as > > doing a better job of decreasing it too > > > >4. (minor) I changed DEF_SAMPLING_RATE_LATENCY_MULTIPLIER to 50000 and > > DEF_SAMPLING_DOWN_FACTOR to 5 as I found the defaults a > >bit annoying > > on my system and resulted in the cpufreq constantly jumping. > > > > For my patch it works far better if the sampling rate > >is much lower > > anyway, which can only be good for cpu efficiency in > >the long run > > Somehow, I feel quick response time for increased load is more > important than smooth increase in frequency. As the CPU latency for > doing the freq transition is lower, I think governor should use that > and do quick adjustments to the freq depending on the load. Probably, I > am thinking more in terms of places where performance is critical. > As Dominik pointed out, it's the time to fork put a new ondemand > governor with this algorithm.... > I have been chatting to a few people and on desktop machines this is the behaviour they of course prefer. Overshoot and then pull down. However all us laptop users have a crotch to protect :) We (well four people out of the *whole* linux community; better than a US poll I hear though) we prefer a overly conservative approach; hence my approach. I did write it to suit more my needs obviously :)
> >5. the grainity of how much cpufreq is increased or decreased > >is controlled > > with sending a percentage to /sys/.../ondemand/freq_step_percent > > > >6. debugging (with 'watch -n1 cat > >/sys/.../ondemand/requested_freq') and > > backwards 'compatibility' to act like the 'userspace' > >governor is > > avaliable with /sys/.../ondemand/requested_freq if > > 'freq_step_percent' is set to zero > > I again agree with Dominik's opinion on this :) > guess the world domination plans go back to....
1. steal all the pants.... 2. .... 3. rule the world
I do though think the step_freq bit should be there.
> Thanks for all the experiments and all these improvements. > I will rollout a patch for ondemand governor soon, by > stealing some code from your patch below :) > Not a problem. I'm in a 'powersaving' mode so will race you if you want to produce those patches :) After that I have to tell 'wmpower' its a Bad Idea(tm) to suck up 5% cpu time to poll for the whole ACPI state every 0.5s with a host of other major issues :-/ Then there is....and...<complains to himself>
Cheers all
Alex
-- _____________________________________ / A bird in the hand is worth what it \ \ will bring. / ------------------------------------- \ ^__^ \ (oo)\_______ (__)\ )\/\ ||----w | || || [unhandled content-type:application/pgp-signature] | |