The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Andrea Righi <arighi@nvidia.com>
To: Tejun Heo <tj@kernel.org>, David Vernet <void@manifault.com>,
	Changwoo Min <changwoo@igalia.com>
Cc: Kuba Piecuch <jpiecuch@google.com>,
	sched-ext@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: [PATCHSET v4 sched_ext/for-7.3] sched_ext: Fix idle CPU state initialization and validation
Date: Mon,  3 Aug 2026 08:08:11 +0200	[thread overview]
Message-ID: <20260803060930.4111746-1-arighi@nvidia.com> (raw)

The built-in idle masks are initialized with all online CPUs marked idle, but
idle tracking currently starts only after sched_ext is fully enabled. This
leaves busy CPUs incorrectly advertised as idle during ops.init() and until
their next idle transition.

Moreover, the allowed_cpus selftest checks that a remotely selected CPU is no
longer present in the idle mask. An idle-to-idle re-pick can re-advertise the
CPU before the test performs this check, making the validation inherently racy.

Fix this by initializing the built-in idle masks empty. This makes the initial
state conservative, so busy CPUs are never incorrectly advertised as idle. Once
the scheduler is enabled and bypass is lifted, the existing idle re-notification
path reschedules every online CPU. Idle-to-idle re-picks then populate the masks
with CPUs that are actually idle.

Also rework the allowed_cpus kselftest to replace the racy remote-CPU check with
a stable local invariant: a CPU running a non-idle scheduling context must not
be advertised as idle.

Changes in v4:
 - Initialize the built-in idle masks empty instead of enabling idle tracking
   before ops.init() and refreshing every CPU under its rq lock (Tejun Heo)
 - Rely on the existing bypass idle re-notification path to populate the masks
   with CPUs that are actually idle
 - Link to v3: https://lore.kernel.org/all/20260731182406.3166853-1-arighi@nvidia.com/

Changes in v3:
 - Reuse the built-in idle-selection static key instead of introducing a
   dedicated idle-tracking key (Kuba Piecuch)
 - Check the local CPU-idle invariant from both ops.select_cpu() and
   ops.enqueue() (Kuba Piecuch)
 - Inspect the idle mask without modifying it and perform the check before
   calling scx_bpf_select_cpu_and() (Kuba Piecuch)
 - Link to v2: https://lore.kernel.org/all/20260731090334.2911948-1-arighi@nvidia.com/

Changes in v2:
 - Move idle-mask initialization from the selftest into the sched_ext
   core (Kuba Piecuch)
 - Add a dedicated idle-tracking static key so transitions are tracked
   before the scheduler is fully enabled (Kuba Piecuch)
 - Rework the allowed_cpus selftest to validate the stable local CPU-idle
   invariant
 - Link to v1: https://lore.kernel.org/all/20260726064754.378671-1-arighi@nvidia.com/

Andrea Righi (2):
      sched_ext: Initialize idle masks as busy
      selftests/sched_ext: Make allowed_cpus idle validation race-free

 kernel/sched/ext/idle.c                            | 16 +++----
 .../testing/selftests/sched_ext/allowed_cpus.bpf.c | 49 ++++++++++++++++++----
 2 files changed, 50 insertions(+), 15 deletions(-)

             reply	other threads:[~2026-08-03  6:09 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-03  6:08 Andrea Righi [this message]
2026-08-03  6:08 ` [PATCH 1/2] sched_ext: Initialize idle masks as busy Andrea Righi
2026-08-03  6:08 ` [PATCH 2/2] selftests/sched_ext: Make allowed_cpus idle validation race-free Andrea Righi
2026-08-03  8:41 ` [PATCHSET v4 sched_ext/for-7.3] sched_ext: Fix idle CPU state initialization and validation Kuba Piecuch
2026-08-03 17:01 ` Tejun Heo

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=20260803060930.4111746-1-arighi@nvidia.com \
    --to=arighi@nvidia.com \
    --cc=changwoo@igalia.com \
    --cc=jpiecuch@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sched-ext@lists.linux.dev \
    --cc=tj@kernel.org \
    --cc=void@manifault.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox