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
Morning all,

On Oct 18, Dominik Brodowski wrote:
>
> Or possibly a "fork" -- different dynamic cpufreq governors aren't a bad
> thing to have. Else the whole modular approach would be wrong... So, even
> if it doesn't get merged into cpufreq_ondemand, you can maintain it as a
> differently named cpufreq governor.
>
but but...that ruins my plans for world domination....

>
> > 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.
>
> Interesting bit, IIRC some userspace tool also does that.
>
if I recall they have to munch through the whole of /proc to get this
information; then again there is probably a clean and fast way of pulling
those time values from /proc that I do not know of.

> > 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
>
> However, this means it takes much longer for the system to react to changes
> in load... it's a tricky issue.
>
its all a case of trade-offs and of course everyones millage will vary. For
me I want the CPU to slowly get faster and faster as a task might complete
fast enough without vamping it up to 100%. Then again Con will probably
point out "pah, then the difference in battery saving is negligable" :)

On a laptop (regardless of whether it gives an overall order of magnitude
power saving or not) I would prefer the cpu speed to be as low as possible.
Again everyone (well here in the UK) I chat to seems to prefer the slow
increasing method which many of the userspace tools try to do anyway; then of
course the argument "userland userland userland....".

> > 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
>
> Please don't do that. Userspace is the governor for userspace frequency
> setting; if you want it, switch to userspace, if you want dynamic frequency
> selection, use the original ondemand or your governor.
>
I thought a few people would grumble about that. I needed a way to store the
variable speed knob and that struct was the best place for it; looks like me
tarting it up as a 'debugging' feature was not good enough :)

Cheers

Alex

--
________________________________________
/ All articles that coruscate with \
\ resplendence are not truly auriferous. /
----------------------------------------
\ ^__^
\ (oo)\_______
(__)\ )\/\
||----w |
|| ||
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2005-03-22 14:07    [W:0.065 / U:0.232 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site