All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kuba Piecuch <jpiecuch@google.com>
To: Andrea Righi <arighi@nvidia.com>, 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: Re: [PATCHSET v4 sched_ext/for-7.3] sched_ext: Fix idle CPU state initialization and validation
Date: Mon, 03 Aug 2026 08:41:36 +0000	[thread overview]
Message-ID: <DKF6AV9R4G9G.21L9Q2OQGK74K@google.com> (raw)
In-Reply-To: <20260803060930.4111746-1-arighi@nvidia.com>

On Mon Aug 3, 2026 at 6:08 AM UTC, Andrea Righi wrote:
> 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(-)

Thanks Andrea, looks good to me!

For the entire series:

Reviewed-by: Kuba Piecuch <jpiecuch@google.com>


  parent reply	other threads:[~2026-08-03  8:41 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-03  6:08 [PATCHSET v4 sched_ext/for-7.3] sched_ext: Fix idle CPU state initialization and validation Andrea Righi
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 ` Kuba Piecuch [this message]
2026-08-03 17:01 ` [PATCHSET v4 sched_ext/for-7.3] sched_ext: Fix idle CPU state initialization and validation 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=DKF6AV9R4G9G.21L9Q2OQGK74K@google.com \
    --to=jpiecuch@google.com \
    --cc=arighi@nvidia.com \
    --cc=changwoo@igalia.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 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.