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 |
|| ||
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:[email protected]]
>Sent: Sunday, January 23, 2005 7:00 AM
>To: [email protected]; Pallipadi, Venkatesh
>Cc: [email protected]; [email protected]
>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 |
> || ||
>
Morning Venki,
On Jan 31, Pallipadi, Venkatesh wrote:
>
> Hi Alex,
>
> Sorry for the late reply. Neat work splitting up all these patches.
>
Not a problem
> I don't think this patch is required as you are initializing a static
> variable. They should be zero without initialization as well.
>
I'll go ahead and fix the lot and then get back to you guys. Might be a week
though as I have just finished moving into my new flat but there are boxes
everywhere and (<insert_sound_of_a_scream/>) no Internet access.
Cheers
Alex
> 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:[email protected]]
> >Sent: Sunday, January 23, 2005 7:00 AM
> >To: [email protected]; Pallipadi, Venkatesh
> >Cc: [email protected]; [email protected]
> >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 |
> > || ||
> >
--
_____________________
< Nice guys get sick. >
---------------------
\ ^__^
\ (oo)\_______
(__)\ )\/\
||----w |
|| ||