From: Dietmar Eggemann <dietmar.eggemann@arm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Bruno Wolff III <bruno@wolff.to>, Josh Boyer <jwboyer@redhat.com>,
"mingo@redhat.com" <mingo@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: Scheduler regression from caffcdd8d27ba78730d5540396ce72ad022aff2c
Date: Thu, 17 Jul 2014 13:23:51 +0200 [thread overview]
Message-ID: <53C7B247.2070309@arm.com> (raw)
In-Reply-To: <20140717090452.GH19379@twins.programming.kicks-ass.net>
On 17/07/14 11:04, Peter Zijlstra wrote:
> On Thu, Jul 17, 2014 at 10:57:55AM +0200, Dietmar Eggemann wrote:
>> There is also the possibility that the memory for sched_group sg is not
>> (completely) zeroed out:
>>
>> sg = kzalloc_node(sizeof(struct sched_group) + cpumask_size(),
>> GFP_KERNEL, cpu_to_node(j));
>>
>>
>> struct sched_group {
>> ...
>> * NOTE: this field is variable length. (Allocated dynamically
>> * by attaching extra space to the end of the structure,
>> * depending on how many CPUs the kernel has booted up with)
>> */
>> unsigned long cpumask[0];
>
> well kZalloc should Zero the entire allocated size, and the specified
> size very much includes the cpumask size as per:
> sizeof(struct sched_group) + cpumask_size()
Yes, I think so too.
>
> But yeah, I'm also a bit puzzled why this goes bang. Makes we worry we
> scribble it somewhere or so.
>
But then, this must be happening in build_sched_domains() between
__visit_domain_allocation_hell()->__sdt_alloc() and build_sched_groups().
Couldn't catch this phenomena by adding a fake SMT level (just a copy of
the real MC level) to my ARM TC2 (dual cluster dual/triple core, no
hyper-threading) to provoke sd degenerate. It does not show the issue
and MC level gets degenerated nicely. Might not be the real example
since SMT and MC are using the same cpu mask here).
@@ -281,6 +281,7 @@ static inline const int cpu_corepower_flags(void)
}
static struct sched_domain_topology_level arm_topology[] = {
+ { cpu_coregroup_mask, cpu_core_flags, SD_INIT_NAME(SMT) },
#ifdef CONFIG_SCHED_MC
{ cpu_corepower_mask, cpu_corepower_flags, SD_INIT_NAME(GMC) },
{ cpu_coregroup_mask, cpu_core_flags, SD_INIT_NAME(MC) },
Maybe by enabling sched_debug on command line (earlyprintk=keep
sched_debug), Bruno could spot topology setup issues on his XEON machine
which could lead to this problem unless the sg cpumask gets zeroed out
in build_sched_groups() a second time ?
Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz dmesg snippet as an example when
booted with 'earlyprintk=keep sched_debug':
...
[ 0.119737] CPU0 attaching sched-domain:
[ 0.119740] domain 0: span 0-1 level SIBLING
[ 0.119742] groups: 0 (cpu_power = 588) 1 (cpu_power = 588)
[ 0.119745] domain 1: span 0-3 level MC
[ 0.119747] groups: 0-1 (cpu_power = 1176) 2-3 (cpu_power = 1176)
...
next prev parent reply other threads:[~2014-07-17 11:24 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-16 14:55 Scheduler regression from caffcdd8d27ba78730d5540396ce72ad022aff2c Bruno Wolff III
2014-07-16 15:17 ` Josh Boyer
2014-07-16 19:17 ` Dietmar Eggemann
2014-07-16 19:54 ` Bruno Wolff III
2014-07-16 23:18 ` Dietmar Eggemann
2014-07-17 3:09 ` Bruno Wolff III
2014-07-17 8:57 ` Dietmar Eggemann
2014-07-17 9:04 ` Peter Zijlstra
2014-07-17 11:23 ` Dietmar Eggemann [this message]
2014-07-17 12:35 ` Peter Zijlstra
2014-07-18 5:34 ` Bruno Wolff III
2014-07-18 9:28 ` Dietmar Eggemann
2014-07-18 12:09 ` Bruno Wolff III
2014-07-18 10:16 ` Peter Zijlstra
2014-07-18 13:01 ` Bruno Wolff III
2014-07-18 14:16 ` Dietmar Eggemann
2014-07-18 14:16 ` Peter Zijlstra
2014-07-18 14:50 ` Peter Zijlstra
2014-07-18 16:16 ` Peter Zijlstra
2014-07-21 16:35 ` Bruno Wolff III
2014-07-21 16:52 ` Peter Zijlstra
2014-07-22 9:47 ` Peter Zijlstra
2014-07-22 10:38 ` Peter Zijlstra
2014-07-22 12:10 ` Bruno Wolff III
2014-07-22 13:03 ` Peter Zijlstra
2014-07-22 13:26 ` Peter Zijlstra
2014-07-22 13:35 ` Peter Zijlstra
2014-07-22 14:09 ` Bruno Wolff III
2014-07-22 14:18 ` Peter Zijlstra
2014-07-23 1:37 ` Bruno Wolff III
2014-07-23 6:51 ` Peter Zijlstra
2014-07-22 17:05 ` H. Peter Anvin
2014-07-23 15:11 ` Peter Zijlstra
2014-07-23 15:12 ` H. Peter Anvin
2014-07-24 1:45 ` Bruno Wolff III
2014-07-23 15:39 ` [tip:x86/urgent] x86, cpu: Fix cache topology for early P4-SMT tip-bot for Peter Zijlstra
2014-07-22 12:12 ` Scheduler regression from caffcdd8d27ba78730d5540396ce72ad022aff2c Dietmar Eggemann
2014-07-22 12:57 ` Bruno Wolff III
2014-07-28 8:28 ` [tip:sched/core] sched: Robustify topology setup tip-bot for Peter Zijlstra
2014-07-17 16:36 ` Scheduler regression from caffcdd8d27ba78730d5540396ce72ad022aff2c Bruno Wolff III
2014-07-17 18:43 ` Dietmar Eggemann
2014-07-17 18:54 ` Bruno Wolff III
2014-07-17 4:21 ` Bruno Wolff III
2014-07-17 4:28 ` Bruno Wolff III
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=53C7B247.2070309@arm.com \
--to=dietmar.eggemann@arm.com \
--cc=bruno@wolff.to \
--cc=jwboyer@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).