From: "Philippe Mathieu-Daudé" <f4bug@amsat.org> To: Alexander Lobakin <alobakin@pm.me>, Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Valentin Schneider <valentin.schneider@arm.com>, Ingo Molnar <mingo@kernel.org>, Peter Zijlstra <peterz@infradead.org>, linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH mips-fixes] MIPS: smp: fill in sibling and core maps earlier Date: Mon, 14 Feb 2022 20:00:12 +0100 [thread overview] Message-ID: <5324be35-5c49-31c1-3f9a-267a5dae8c84@amsat.org> (raw) In-Reply-To: <20220212221347.442070-1-alobakin@pm.me> On 12/2/22 23:21, Alexander Lobakin wrote: > After enabling CONFIG_SCHED_CORE (landed during 5.14 cycle), > 2-core 2-thread-per-core interAptiv (CPS-driven) started emitting > the following: > > [ 0.025698] CPU1 revision is: 0001a120 (MIPS interAptiv (multi)) > [ 0.048183] ------------[ cut here ]------------ > [ 0.048187] WARNING: CPU: 1 PID: 0 at kernel/sched/core.c:6025 sched_core_cpu_starting+0x198/0x240 > [ 0.048220] Modules linked in: > [ 0.048233] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.17.0-rc3+ #35 b7b319f24073fd9a3c2aa7ad15fb7993eec0b26f > [ 0.048247] Stack : 817f0000 00000004 327804c8 810eb050 00000000 00000004 00000000 c314fdd1 > [ 0.048278] 830cbd64 819c0000 81800000 817f0000 83070bf4 00000001 830cbd08 00000000 > [ 0.048307] 00000000 00000000 815fcbc4 00000000 00000000 00000000 00000000 00000000 > [ 0.048334] 00000000 00000000 00000000 00000000 817f0000 00000000 00000000 817f6f34 > [ 0.048361] 817f0000 818a3c00 817f0000 00000004 00000000 00000000 4dc33260 0018c933 > [ 0.048389] ... > [ 0.048396] Call Trace: > [ 0.048399] [<8105a7bc>] show_stack+0x3c/0x140 > [ 0.048424] [<8131c2a0>] dump_stack_lvl+0x60/0x80 > [ 0.048440] [<8108b5c0>] __warn+0xc0/0xf4 > [ 0.048454] [<8108b658>] warn_slowpath_fmt+0x64/0x10c > [ 0.048467] [<810bd418>] sched_core_cpu_starting+0x198/0x240 > [ 0.048483] [<810c6514>] sched_cpu_starting+0x14/0x80 > [ 0.048497] [<8108c0f8>] cpuhp_invoke_callback_range+0x78/0x140 > [ 0.048510] [<8108d914>] notify_cpu_starting+0x94/0x140 > [ 0.048523] [<8106593c>] start_secondary+0xbc/0x280 > [ 0.048539] > [ 0.048543] ---[ end trace 0000000000000000 ]--- > [ 0.048636] Synchronize counters for CPU 1: done. > > ...for each but CPU 0/boot. > Basic debug printks right before the mentioned line say: > > [ 0.048170] CPU: 1, smt_mask: > > So smt_mask, which is sibling mask obviously, is empty when entering > the function. > This is critical, as sched_core_cpu_starting() calculates > core-scheduling parameters only once per CPU start, and it's crucial > to have all the parameters filled in at that moment (at least it > uses cpu_smt_mask() which in fact is `&cpu_sibling_map[cpu]` on > MIPS). > > A bit of debugging led me to that set_cpu_sibling_map() performing > the actual map calculation, was being invocated after > notify_cpu_start(), and exactly the latter function starts CPU HP > callback round (sched_core_cpu_starting() is basically a CPU HP > callback). > While the flow is same on ARM64 (maps after the notifier, although > before calling set_cpu_online()), x86 started calculating sibling > maps earlier than starting the CPU HP callbacks in Linux 4.14 (see > [0] for the reference). Neither me nor my brief tests couldn't find > any potential caveats in calculating the maps right after performing > delay calibration, but the WARN splat is now gone. > The very same debug prints now yield exactly what I expected from > them: > > [ 0.048433] CPU: 1, smt_mask: 0-1 > > [0] https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=76ce7cfe35ef Isn't it worth Cc'ing stable@vger.kernel.org here? > Signed-off-by: Alexander Lobakin <alobakin@pm.me> > --- > arch/mips/kernel/smp.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
WARNING: multiple messages have this Message-ID (diff)
From: Alexander Lobakin <alobakin@pm.me> To: "Philippe Mathieu-Daudé" <f4bug@amsat.org>, "Thomas Bogendoerfer" <tsbogend@alpha.franken.de> Cc: Alexander Lobakin <alobakin@pm.me>, Valentin Schneider <valentin.schneider@arm.com>, Ingo Molnar <mingo@kernel.org>, Peter Zijlstra <peterz@infradead.org>, linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH mips-fixes] MIPS: smp: fill in sibling and core maps earlier Date: Tue, 15 Feb 2022 14:49:00 +0000 [thread overview] Message-ID: <5324be35-5c49-31c1-3f9a-267a5dae8c84@amsat.org> (raw) Message-ID: <20220215144900.HgPShB3Qm8JBGGDhbvY5csF4uTmTe5213trVKH8JlZM@z> (raw) From: Philippe Mathieu-Daudé <f4bug@amsat.org> Date: Mon, 14 Feb 2022 20:00:12 +0100 > On 12/2/22 23:21, Alexander Lobakin wrote: > > After enabling CONFIG_SCHED_CORE (landed during 5.14 cycle), > > 2-core 2-thread-per-core interAptiv (CPS-driven) started emitting > > the following: > > --- 8< --- > > > > [ 0.048433] CPU: 1, smt_mask: 0-1 > > > > [0] https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=76ce7cfe35ef > > Isn't it worth Cc'ing stable@vger.kernel.org here? Probably. It doesn't have any Fixes tag (this is a fix, but the bug is caused not by a particular commit, rather by a combination of changes and code flows from the past), but it still can be backported, right. Thomas, should I queue a v2 with this tag added? Cc: stable@vger.kernel.org # 5.14+ Or it can be picked up automatically? > > > Signed-off-by: Alexander Lobakin <alobakin@pm.me> > > --- > > arch/mips/kernel/smp.c | 6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > > Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Thanks! Al
next prev parent reply other threads:[~2022-02-14 19:05 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-02-12 22:21 [PATCH mips-fixes] MIPS: smp: fill in sibling and core maps earlier Alexander Lobakin 2022-02-14 19:00 ` Philippe Mathieu-Daudé [this message] 2022-02-15 14:49 ` Alexander Lobakin 2022-02-16 19:50 ` Thomas Bogendoerfer
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=5324be35-5c49-31c1-3f9a-267a5dae8c84@amsat.org \ --to=f4bug@amsat.org \ --cc=alobakin@pm.me \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mips@vger.kernel.org \ --cc=mingo@kernel.org \ --cc=peterz@infradead.org \ --cc=tsbogend@alpha.franken.de \ --cc=valentin.schneider@arm.com \ /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: linkBe 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).