On Thu, Mar 10, 2016 at 12:28:52AM +0100, Rafael J. Wysocki wrote: > > [ I would not have chosen (1 + 1/n), but lets stick to that ] > > Well, what would you choose then? :-) 1/p ; 0 < p < 1 or so. Where p then represents the percentile threshold where you want to bump to the next freq. > I think that should be > > next_freq = (1 + 1/n) * max_freq * util / max > > (where max is the second argument of cpufreq_update_util) or the > dimensions on both sides don't match. Well yes, but so far we were treating util (and util_raw) as 0 < u < 1, values, so already normalized against max. But yes.. > > if we substitute (2) into (3) we get: > > > > = (1 + 1/n) * max_freq * util_raw * current_freq / max_freq > > = (1 + 1/n) * current_freq * util_raw (4) > > > > Which gets you two formula with the same general behaviour. As (2) is > > the only approximation of (1) we can make. > > OK > > So since utilization is not frequency invariant in the current > mainline (or linux-next for that matter) AFAIC, I'm going to use the > following in the next version of the schedutil patch series: > > next_freq = 1.25 * current_freq * util_raw / max > > where util_raw and max are what I get from cpufreq_update_util(). > > 1.25 is for the 80% tipping point which I think is reasonable. OK. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
