Messages in this thread | | | Date | Mon, 18 Oct 2004 09:25:08 +0100 | From | Alexander Clouter <> | Subject | Re: [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] | |