Hi Viresh, On 03/05/2013 02:23 AM, Viresh Kumar wrote:> Interesting. Because it was removed earlier and no body complained :) > > I got following from Documentation: > > sampling_down_factor: this parameter controls the rate at which the > kernel makes a decision on when to decrease the frequency while running > at top speed. When set to 1 (the default) decisions to reevaluate load > are made at the same interval regardless of current clock speed. But > when set to greater than 1 (e.g. 100) it acts as a multiplier for the > scheduling interval for reevaluating load when the CPU is at its top > speed due to high load. This improves performance by reducing the overhead > of load evaluation and helping the CPU stay at its top speed when truly > busy, rather than shifting back and forth in speed. This tunable has no > effect on behavior at lower speeds/lower CPU loads. > > And i believe we are supposed to check if we are at the top speed or not. > Over that i believe the code should be like: > > While setting speed to top speed, set the timer to delay * sampling_down_factor, > so that we actually don't reevaluate the load. What do you say? > I had the same thoughts, but I saw the comments in the code: /* * Every sampling_rate, we check, if current idle time is less than 20% * (default), then we try to increase frequency Every sampling_rate * * sampling_down_factor, we check, if current idle time is more than 80%, then * we try to decrease frequency * Also checking the code before the commit 8e677ce83bf41ba9c74e5b6d9ee60b07d4e5ed93 you may see that sampling down factor works in this way. So, I decided to keep the original functionality (also down_skip was already there unused). Regards, Stratos -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
