RE: [PATCH] cpufreq_ondemand

[Pallipadi, Venkatesh]

>-----Original Message-----
>From:       Alexander Clouter <alex-kernel () digriz ! org ! uk>
>Date:       2004-10-17 22:29:16
>Message-ID: <20041017222916.GA30841 () inskipp ! digriz ! org ! uk>
>[Download message RAW]
>
>[Attachment #2 (multipart/mixed)]
>
>
>Hi all,
>
>After playing with the cpufreq_ondemand governor (many thanks 
>to those whom 
>made it) I made a number of alterations which suit me at 
>least.  Really 
>looking for feedback and of course once people have fixed any 
>bugs they find 
>and made the code look neater, possible inclusion?
>
>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.
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.

Note, I haven't really run your version yet. This is what 
I feel by looking at the patch. I may well be wrong.

> 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.

>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....

>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 :)

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 :)

Thanks,
Venki

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/