From: Dietmar Eggemann <dietmar.eggemann@arm.com>
To: lkp@lists.01.org
Subject: Re: [sched] WARNING: CPU: 0 PID: 0 at arch/x86/kernel/cpu/common.c:1439 warn_pre_alternatives()
Date: Fri, 19 Dec 2014 15:51:22 +0100 [thread overview]
Message-ID: <54943B6A.9050309@arm.com> (raw)
In-Reply-To: <20141210232645.GD24163@wfg-t540p.sh.intel.com>
[-- Attachment #1: Type: text/plain, Size: 2295 bytes --]
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.eggemann@arm.com>
> AuthorDate: Tue Dec 2 14:06:24 2014 +0000
> Commit: Michael Turquette <mturquette@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 <mingo@redhat.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Signed-off-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
>
[...]
WARNING: multiple messages have this Message-ID (diff)
From: Dietmar Eggemann <dietmar.eggemann@arm.com>
To: Fengguang Wu <fengguang.wu@intel.com>
Cc: Michael Turquette <mturquette@deferred.io>, LKP <lkp@01.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [sched] WARNING: CPU: 0 PID: 0 at arch/x86/kernel/cpu/common.c:1439 warn_pre_alternatives()
Date: Fri, 19 Dec 2014 15:51:22 +0100 [thread overview]
Message-ID: <54943B6A.9050309@arm.com> (raw)
In-Reply-To: <20141210232645.GD24163@wfg-t540p.sh.intel.com>
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.eggemann@arm.com>
> AuthorDate: Tue Dec 2 14:06:24 2014 +0000
> Commit: Michael Turquette <mturquette@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 <mingo@redhat.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Signed-off-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
>
[...]
next prev parent reply other threads:[~2014-12-19 14:51 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-10 23:20 [sched] BUG: unable to handle kernel Fengguang Wu
2014-12-10 23:20 ` Fengguang Wu
2014-12-10 23:26 ` [sched] WARNING: CPU: 0 PID: 0 at arch/x86/kernel/cpu/common.c:1439 warn_pre_alternatives() Fengguang Wu
2014-12-10 23:26 ` Fengguang Wu
2014-12-10 23:56 ` Borislav Petkov
2014-12-10 23:56 ` Borislav Petkov
2014-12-19 14:51 ` Dietmar Eggemann [this message]
2014-12-19 14:51 ` Dietmar Eggemann
2014-12-10 23:31 ` [sched] Initramfs unpacking failed: junk in compressed archive Fengguang Wu
2014-12-10 23:31 ` Fengguang Wu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54943B6A.9050309@arm.com \
--to=dietmar.eggemann@arm.com \
--cc=lkp@lists.01.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.