From: Fernand Sieber <sieberf@amazon.com>
To: <mingo@redhat.com>, <peterz@infradead.org>,
<juri.lelli@redhat.com>, <vincent.guittot@linaro.org>,
<shuah@kernel.org>
Cc: <dietmar.eggemann@arm.com>, <rostedt@goodmis.org>,
<bsegall@google.com>, <mgorman@suse.de>, <vschneid@redhat.com>,
<kprateek.nayak@amd.com>, <linux-kernel@vger.kernel.org>,
<linux-kselftest@vger.kernel.org>, <nh-open-source@amazon.com>,
<hborghor@amazon.de>, <fmubeen@amazon.de>, <dwmw@amazon.co.uk>
Subject: [PATCH 0/2] sched/fair: Stop core-scheduled siblings trading rescheduling IPIs
Date: Mon, 9 Nov 2026 21:48:25 +0200 [thread overview]
Message-ID: <20261109194827.87349-1-sieberf@amazon.com> (raw)
Since v6.17, two SMT siblings under core scheduling can keep sending each
other rescheduling IPIs, thousands per CPU per second, while each keeps
running the same task.
Commit 0b9ca2dcabc3 ("sched/fair: Always trigger resched at the end of a
protected period") makes update_curr() ask for a reschedule once the
running entity's protected period has expired. set_protect_slice() only
rearms that period on a fresh pick (SNT_PICK), so an entity that is picked
again keeps an expired vprot and every later update_curr() on it asks
again. Under core scheduling the ask is remote: a core wide pick calls
pick_task() - hence update_curr() - on every sibling's runqueue, so each
sibling IPIs the other, which schedules, re-picks the same entity, renews
nothing, and IPIs back.
Patch 1 renews the protection on a repick. Patch 2 adds a selftest that
cookies one SMT pair, runs two spinners on each sibling and fails above
1000 rescheduling IPIs per CPU per second. It reproduces in a 4 vCPU QEMU
guest (-smp 4,sockets=1,cores=2,threads=2) with CONFIG_SCHED_CORE=y and
CONFIG_PREEMPT_LAZY=n: without patch 1 it fails 6 runs out of 7, at
808-2123 IPIs/CPU/s; with it all 7 pass, at 224-271.
This series, including the changelogs, was prepared with the help of an AI
coding assistant; I have reviewed and tested all of it.
Fernand Sieber (2):
sched/fair: Renew slice protection when current is picked again
selftests/sched: Add a core scheduling rescheduling IPI test
kernel/sched/fair.c | 7 +
tools/testing/selftests/sched/.gitignore | 1 +
tools/testing/selftests/sched/Makefile | 4 +-
tools/testing/selftests/sched/config | 2 +-
.../selftests/sched/cs_resched_ipi_test.c | 377 ++++++++++++++++++
5 files changed, 388 insertions(+), 3 deletions(-)
create mode 100644 tools/testing/selftests/sched/cs_resched_ipi_test.c
--
2.47.3
Amazon Development Centre (South Africa) (Proprietary) Limited
29 Gogosoa Street, Observatory, Cape Town, Western Cape, 7925, South Africa
Registration Number: 2004 / 034463 / 07
next reply other threads:[~2026-11-09 19:48 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-09 19:48 Fernand Sieber [this message]
2026-11-09 19:48 ` [PATCH 1/2] sched/fair: Renew slice protection when current is picked again Fernand Sieber
2026-11-09 19:48 ` [PATCH 2/2] selftests/sched: Add a core scheduling rescheduling IPI test Fernand Sieber
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=20261109194827.87349-1-sieberf@amazon.com \
--to=sieberf@amazon.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=dwmw@amazon.co.uk \
--cc=fmubeen@amazon.de \
--cc=hborghor@amazon.de \
--cc=juri.lelli@redhat.com \
--cc=kprateek.nayak@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=nh-open-source@amazon.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=shuah@kernel.org \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.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: 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.