Most recent kernel where this bug did *NOT* occur: none, all kernels >=2.6.13 are affected (this governor was added in 2.6.13 if I well remember...) Distribution: Slackware 11.0 Hardware Environment: Asus laptop with amd athlon xp-m 2800+ Software Environment: Problem Description: When conservative governor is selected, the minimun and maximum sampling rate are set to a value 10 times higher than normal, and the governor looks at system load only 1 times per second approximately. On my laptop, the ondemand governor has a minimum sampling rate of 99500 (0.0995 seconds) while with conservative this value is 995000 (0.995 seconds). If one considers that the default sampling rate is set to 2*minimum, most of users will find the conservative governor useless if they don't know how to modify it, because the system will not respond to a rapid increasing load. The reason of this bug is a wrong defined value in the source file of conservative. If you look at conservative.c at line 497, you will find this: def_sampling_rate = 10 * latency * DEF_SAMPLING_RATE_LATENCY_MULTIPLIER; this should be changed to: def_sampling_rate = latency * DEF_SAMPLING_RATE_LATENCY_MULTIPLIER; as is in the ondemand governor. I've recompiled the module with this change and now conservative works fine. My values Conservative governor (2.6.18 kernel from kernel.org): a cat in the conservative folder shows: bash-3.1# cat sampling_rate_min sampling_rate_max 995000 995000000 Patched conservative (with the correction indicated above): bash-3.1# cat sampling_rate_min sampling_rate_max 99500 99500000 Ondemand governor (2.6.18 kernel from kernel.org): bash-3.1# cat sampling_rate_min sampling_rate_max 99500 99500000 Steps to reproduce: cd /sys/devices/system/cpu/cpu0/cpufreq/ echo ondemand > scaling_governor than take a look in the ondemand folder at files sampling_rate_min, sampling_rate_max, sampling rate. Than do the same thing with conservative: echo conservative > scaling_governor and compare the values. You will see that these values are from 10 times (most recents kernels) to 100 times (kernels 2.6.13 from 2.6.15) higher than ondemand sets. You can also load the cpufreq_stats module and look in the stats folder (/sys/.../cpufreq/stats). You will see that ondemand causes a lot of transitions, while conservative does not.
Created attachment 10530 [details] This is a simple patch to fix the bug. Apply it at conservative.c
This patch needs a review, adding CCs. Thanks.
I was trying to figure out why the conservative governor didn't seem to work on my amd64 system, and ran across this bug and some other info. I think that 10 * latency bit for the default sampling rate was deliberate, since it was introduced as a standalone patch some time ago: http://osdir.com/ml/kernel.cpufreq/2006-03/msg00048.html However, that patch neglected to make a corresponding change to the rules for the minimum sampling rate. The result is that, on my amd64 system, the default sampling rate is 12.4 seconds, and the fastest rate is 6.2 seconds. My CPU (athlon64 x2 4400) has speeds of 1000, 1800, 2000, and 2200 MHz available to cpufreq. With the defaults in the conservative governor then, it will take it 99.2 seconds at full load to decide to notch it up from 1000 to 1800MHz (8 sampling rates each stepping the target speed by 100MHz). This calculation matches with some empirical observations I did. I see two fixes that should be made from this: 1) The MIN_SAMPLING_RATE_RATIO define should be changed from 2 to 20, to match the 10x change in the default sampling rate. This would at least allow saner configurations to be put in place by hand. 2) Instead of stepping the target frequency by a mythical 5% that probably cannot be satisified by hardware, shouldn't it just step it up or down one entry in the available frequencies table?
(In reply to comment #3) > > I think that 10 * latency bit for the default sampling rate was deliberate, > since it was introduced as a standalone patch some time ago: > http://osdir.com/ml/kernel.cpufreq/2006-03/msg00048.html > Yes it was, the idea was to prevent the governor being as trigger happy as ondemand; without it you would go from [min-freq]->[max-freq] in about 0.5 seconds :) Stefano has been bugging me about this for ages but keeps wanting me just to blat def_sampling_rate to what it used to be when I forked conservative from ondemand. It was my bad to not deal with this problem eariler. > However, that patch neglected to make a corresponding change to the rules for > the minimum sampling rate. > > The result is that, on my amd64 system, the default sampling rate is 12.4 > seconds, and the fastest rate is 6.2 seconds. > > My CPU (athlon64 x2 4400) has speeds of 1000, 1800, 2000, and 2200 MHz > available to cpufreq. With the defaults in the conservative governor then, > it > will take it 99.2 seconds at full load to decide to notch it up from 1000 to > 1800MHz (8 sampling rates each stepping the target speed by 100MHz). This > calculation matches with some empirical observations I did. > > I see two fixes that should be made from this: > > 1) The MIN_SAMPLING_RATE_RATIO define should be changed from 2 to 20, to > match > the 10x change in the default sampling rate. This would at least allow saner > configurations to be put in place by hand. > > 2) Instead of stepping the target frequency by a mythical 5% that probably > cannot be satisified by hardware, shouldn't it just step it up or down one > entry in the available frequencies table? > The mythical 5% is there try and produce a result that is more like a smooth change through speed. It was done, this was the plan at least, so that in a fixed time period and at full load on any machine the governor would move from the minimum to highest clock speed. Obviously this is not happening so it is back to the drawing board. It is not simple to just pull the frequencies and step through those, it was beyond my understanding of C and the kernel (I think I vaguely recall someone back in the midst's of time saying this was a Bad Idea and not possible anyway) to import them into the governor besides the final result of either stepping in 5% incremements or the actually frequencies themselves is the same; I would just say in the latter case it makes it easier to true to bring in a 'constant time' element. Anyway, now I know there are at least two folks suffering this problem I'll look into fixing it but it might be a month before something is produced; Real Life has hit me pretty hard with work and finding a place to live. Cheers Alex
(In reply to comment #4) > It is not simple to just pull the frequencies and step through those, it was > beyond my understanding of C and the kernel (I think I vaguely recall someone > back in the midst's of time saying this was a Bad Idea and not possible > anyway) > to import them into the governor besides the final result of either stepping > in > 5% incremements or the actually frequencies themselves is the same; I would > just say in the latter case it makes it easier to true to bring in a > 'constant > time' element. Your point about the complexities, benefits, and constant-time-ness of using mythical vs. available frequencies are good, I though I'd just note that I brought up the stepping through the table of available frequencies because I thought I saw code in the ondemand governor to do something like that. The powersave_bias_target and ondemand_powersave_bias_init seem to work with that information. > Anyway, now I know there are at least two folks suffering this problem I'll > look into fixing it but it might be a month before something is produced; > Real > Life has hit me pretty hard with work and finding a place to live. Understandable. For me, just the little fix for the minimum sample rate is sufficient, as that allows me to set a sample rate and frequency step that produce reasonable behavior.
Alex, I was sorry to hear your remark about life situation - hope it all improved.
Any update on this problem please? - thanks.
For me this problem worsened a lot with the recent switch from 2.6.21 to 2.6.25 because the sampling_rate_min is now extremely big, like 2.5 seconds. I used a way smaller value before and it worked very sufficiently. I'll go and patch my kernal now but I strongly believe this should be changed back soon.
Created attachment 16206 [details] update to cpufreq_conservative A combo patch that re-sync's some of the differences between ondemand and conservative and fixes the (trivial) long standing issue of long transistion times on some (all?) AMD boxen. If there are any problems then let me know (enabled the '#define DEBUG' in the code first though).
I do have a 'time based' scaling prototype for cpufreq_conservative which seems to work incase relying on transistion times turns out to be annoying. I personally think it's not worth the effort but others might; a 'summary' of what I am talking about: /* * Every sampling_rate, we check if the idle time is less * than 20% (default). If this is the case then the logic that makes * behind the conservative governor's profile is consulted. * * ================================================================= * TODO: move to Documentation/cpu-freq/governors.txt * * CPU load > 80% @ 0 -> t_2 * CPU load < 70% @ t_2 -> t_3 * * freq * ^ * | * max +. . . ______. . . . _ . . . . . . . . . . . . . * | / \ _/:\__ * | | | _/ : \__ * | | | _/ : \__ * | | \/ : \__ * | | _/: : \__ * | | _/ : : \__ * | |_/ : : \__ * min +_____/. . . . . . . . . . . . . . . . . . \_. . * | : : : : * | : : : : * | : : : : * -+-----+------+-------+----------------------+--> t * 0 t_0 t_1 t_2 t_3 * * t_0 = [ delay_time ( == 0 || >= 2*sampling_rate )] * t_1 = t_0 + [ burst_time ( == 0 || >= 2*sampling_rate ) ] * t_2 = t_0 + [ rise_time ( >= 2*sampling_rate ) ] * t_3 = t_2 + [ fall_time ( >= 2*sampling_rate ) ] * * The 'hill' profile is maintained independently of the burst section, * the burst profile when in effect overrides the underlying profile. * ================================================================= */
I forgot to mention that with the patch I supplied I do have a patch-set on me but want to see if this works fine (as a single patch for folk to use). Also a bug is fixed that deals with the interesting case of when cpufreq_conservative updates the cpufreq and then a trigger resets the cpu speed back to min :-/
*** Bug 7056 has been marked as a duplicate of this bug. ***
There was a change in 2.6.27 that substantially reduced the minimum sampling rate of AMD processors. Does that resolve the issue?
(In reply to comment #13) > There was a change in 2.6.27 that substantially reduced the minimum sampling > rate of AMD processors. Does that resolve the issue? I'm now running 2.6.32.5 on an "AMD Athlon(tm) 64 X2 Dual Core Processor 5000+" (according to /proc/cpuinfo, not sure if that's exactly the correct model number ... it's a 2.6GHz Athlon 64 x2). I just gave the conservative governor a whirl with the default sampling rate and other settings, and it does indeed seem to be resolved. Under load the cpu moves up the speed steps over the course of a couple seconds. Watching it rapidly, it seems like it's changing once or twice a second as load is applied and removed, which seems reasonable for what it's trying to do. Can produce amusing cyclic affects with mplayer's -autoq mode ;)
Thanks for testing the fix.
Conservative is fully working for me now, I'm running a 2.6.32 kernel and it is doing its job very well! In particular, the sampling rate is now aligned with that of ondemand and my system is faster. Thanks to all who worked on this problem. Stefano