lkml.org 
[lkml]   [2004]   [Oct]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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]
\
 
 \ /
  Last update: 2005-03-22 14:07    [W:0.042 / U:0.400 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site