Hi Fengguang,
On 11/12/14 00:26, Fengguang Wu wrote:
Hi Dietmar,
FYI, here is another bisect result.
thanks for testing this on another arch then ARM!
The problem is that the weak arch_scale_cpu_capacity calls
default_scale_cpu_capacity on a system which doesn't overwrite it and
the default one accesses the sched_domain which is not allocated that
early when called by scheduler_tick.
I only tested it on an ARM system which in this tree which overwrites
arch_scale_cpu_capacity and does not access sched_domain.
Have to look into it and will test the default case from now on too.
-- Dietmar
https://git.linaro.org/people/mturquette/linux.git eas-next
commit 1fadb581b0be9420b143e43ff2f4a07ea7e45f6c
Author: Dietmar Eggemann <dietmar.eggem...@arm.com>
AuthorDate: Tue Dec 2 14:06:24 2014 +0000
Commit: Michael Turquette <mturque...@deferred.io>
CommitDate: Tue Dec 9 20:33:17 2014 -0800
sched: Make usage and load tracking cpu scale-invariant
Besides the existing frequency scale-invariance correction factor, apply
cpu scale-invariance correction factor to usage and load tracking.
Cpu scale-invariance takes cpu performance deviations due to
micro-architectural differences (i.e. instructions per seconds) between
cpus in HMP systems (e.g. big.LITTLE) and differences in the frequency
value of the highest OPP between cpus in SMP systems into consideration.
Each segment of the sched_avg::{running_avg_sum, runnable_avg_sum}
geometric series is now scaled by the cpu performance factor too so the
sched_avg::{utilization_avg_contrib, load_avg_contrib} of each entity will
be invariant from the particular cpu of the HMP/SMP system it is gathered
on. As a result, cfs_rq::runnable_load_avg which is the sum of
sched_avg::load_avg_contrib, becomes cpu scale-invariant too.
So the {usage, load} level that is returned by {get_cpu_usage,
weighted_cpuload} stays relative to the max cpu performance of the system.
Cc: Ingo Molnar <mi...@redhat.com>
Cc: Peter Zijlstra <pet...@infradead.org>
Signed-off-by: Dietmar Eggemann <dietmar.eggem...@arm.com>
[...]
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
