On Mon, Nov 03, 2014 at 04:54:41PM +0000, Vincent Guittot wrote: > From: Morten Rasmussen <[email protected]> > > Apply frequency scale-invariance correction factor to usage tracking.
s/usage/utilization/ > Each segment of the running_load_avg geometric series is now scaled by the > current frequency so the utilization_avg_contrib of each entity will be s/entity/sched_entity/ > invariant with frequency scaling. As a result, utilization_load_avg which is > the sum of utilization_avg_contrib, becomes invariant too. So the usage level s/sum of utilization_avg_contrib/sum of sched_entity utilization_avg_contribs/ s/usage/utilization/ > that is returned by get_cpu_usage, stays relative to the max frequency as the > cpu_capacity which is is compared against. The last bit doesn't parse right. '... Maybe it is better to drop the reference to get_cpu_usage which hasn't been defined yet and rewrite the thing to: Apply frequency scale-invariance correction factor to utilization tracking. Each segment of the running_load_avg geometric series is now scaled by the current frequency so the utilization_avg_contrib of each entity will be invariant with frequency scaling. As a result, utilization_load_avg which is the sum of sched_entity utilization_avg_contribs becomes invariant too and is now relative to the max utilization at the max frequency (=cpu_capacity). I think we should add: arch_scale_freq_capacity() is reintroduced to provide the frequency compensation scaling factor. > Then, we want the keep the load tracking values in a 32bits type, which > implies s/Then, we/We/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
