RE: [PATCH] cpufreq_(ondemand|conservative)

[Pallipadi, Venkatesh]

Hi Alex,

Sorry for the late reply. Neat work splitting up all these patches. 

>5) cpufreq_ondemand-2.6.11-rc1-mm1-05_safe_down_skip.diff
>	although I have not noticed any problems without it 
>being done a 
>	little alarm bell fires off in my head about how 
>down_skip really 
>	should be initialised (what if the cpu-freq is not at a 
>minimum when 
>	we start off or ac power is unplugged and we get 
>policy->min changing 
>	to a lower value?).  Again a minor patch, if not worth 
>it obviously 
>	it can be removed and should also be from cpufreq_conservative

I don't think this patch is required as you are initializing a static
variable. They should be zero without initialization as well.

All patches except the above looks good and ready to go. Can you send
them individually to cpufreq list, with Signed-off line.

Thanks,
Venki 
 

>-----Original Message-----
>From: Alexander Clouter [mailto:alex@xxxxxxxxxxxxx] 
>Sent: Sunday, January 23, 2005 7:00 AM
>To: linux@xxxxxxxxxxxxxxxxxxx; Pallipadi, Venkatesh
>Cc: linux-kernel@xxxxxxxxxxxxxxx; cpufreq@xxxxxxxxxxxxxxxxxx
>Subject: [PATCH] cpufreq_(ondemand|conservative)
>
>Hi All,
>
>Well after Dominik reminded me about the updates to 
>cpufreq_ondemand I had
>made some time back and also my cpufreq governor called 
>cpufreq_conservative,
>I dug out my coffee and started fixing them up for another 
>round of peer
>review.  My governor is pretty much a minor rewrite of the 
>cpufreq_ondemand
>governor but instead gracefully increases and decreases the 
>cpufreq which
>should make it much more suitable for battery power environments.
>
>All the patches are for 2.6.11-rc1-mm1 but also apply cleanly to
>2.6.11-rc1-mm2.  Unfortunately 2.6.11-rc1-mm2 oops'es in key_scancode
>(drivers/char/keyboard.c) when I presses any keys on my text 
>console (tty1)
>after init has loaded so I am waiting till 2.6.11-rc2-mm1 
>appears before I
>file a bug report.
>
>The 'improvements' I have made to cpufreq_ondemand are:
>
>1) cpufreq_ondemand-2.6.11-rc1-mm1-01_ignore-nice.diff
>	this adds a new parameter in /sys called
>	/sys/.../cpufreq/ondemand/ignore_nice which by default 
>is set to '0'.
>	Any 'nice' tasks running will be considered as idle 
>time unless you 
>	set the value in ignore_nice to '1', then it will be simply 
>	considered as a regular cpu time sucking program.
>
>	Last time I did this Venki mentioned some possible corner case 
>	conditions[1] and so this time I make it recalculate 
>the idle times 
>	when the value of ignore_nice is flipped.  If I am 
>right this should 
>	fix any possible issues that would have arisen from this...?
>
>2) cpufreq_ondemand-2.6.11-rc1-mm1-02_check-rate-and-break-out.diff
>	a very simple patch which prevents us from changing the 
>cpufreq from 
>	'x' to 'x' un-necessarily.  No-one could find any 
>problems with this 
>	so it has pretty much remained untouched.
>
>3) cpufreq_ondemand-2.6.11-rc1-mm1-03_sys_freq_step.diff
>	this feature also adds a new parameter in /sys called
>	/sys/.../cpufreq/ondemand/freq_step which by default is 
>set to '5'.  
>	You can change this to any value between '0' (why?) and 
>'100' to 
>	alter how much the cpu will change its frequency by on 
>the way down.
>
>4) cpufreq_ondemand-2.6.11-rc1-mm1-04_ignore_steal.diff
>	I noticed a new cpustat has appeared called 'steal'[2] 
>which from 
>	what I can tell should be treated like an iowait stat.  
>'steal' only 
>	seems supported by S/390 but I think it should be 
>'considered'.  This 
>	is a minor patch and if I have gotten confused then 
>obviously it 
>	should be removed (and from cpufreq_conservative)
>
>5) cpufreq_ondemand-2.6.11-rc1-mm1-05_safe_down_skip.diff
>	although I have not noticed any problems without it 
>being done a 
>	little alarm bell fires off in my head about how 
>down_skip really 
>	should be initialised (what if the cpu-freq is not at a 
>minimum when 
>	we start off or ac power is unplugged and we get 
>policy->min changing 
>	to a lower value?).  Again a minor patch, if not worth 
>it obviously 
>	it can be removed and should also be from cpufreq_conservative
>
>Now cpufreq_conservative started off as a copy of 
>cpufreq_ondemand with all
>the above patches and then amended from there.  If you install 
>the patches
>you can see with a diff (attached for _show_ and not use) that 
>there is not
>much in the way of difference between them.  It works by me 
>creating and
>initialising an array to each cpu's policy->cur (this could 
>should be nice in 
>an SMP environment, bug reports would be appreciated) and then 
>changing the 
>contents by freq_step each time we need to increase or 
>decrease the cpufreq.  
>This results in a smoother transition on the way up and down.  
>Also by the 
>nature of this governor it polls 100 times fewer than cpufreq_ondemand.
>
>Let me know what you think, the patches work for me, the 
>question is do they 
>work for you :)
>
>Cheers all
>
>Alex
>
>[1] http://marc.theaimsgroup.com/?l=linux-kernel&m=110013659005496&w=2
>[2] http://marc.theaimsgroup.com/?l=linux-kernel&m=109888788719020&w=2
>
>-- 
> ________________________________________ 
>/ A foolish consistency is the hobgoblin \
>| of little minds.                       |
>|                                        |
>\ -- Ralph Waldo Emerson                 /
> ---------------------------------------- 
>        \   ^__^
>         \  (oo)\_______
>            (__)\       )\/\
>                ||----w |
>                ||     ||
>
-
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/