From: Tejun Heo <tj@kernel.org>
To: Andrea Righi <arighi@nvidia.com>
Cc: David Vernet <void@manifault.com>,
Changwoo Min <changwoo@igalia.com>,
Kuba Piecuch <jpiecuch@google.com>,
sched-ext@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] sched_ext: Initialize idle masks before ops.init()
Date: Sun, 2 Aug 2026 09:19:48 -1000 [thread overview]
Message-ID: <am-YVNN5Ga12zHpM@slm.duckdns.org> (raw)
In-Reply-To: <20260731182406.3166853-2-arighi@nvidia.com>
Hello,
On Fri, Jul 31, 2026 at 08:23:33PM +0200, Andrea Righi wrote:
> The built-in idle masks are reset with all online CPUs marked idle, but
> idle state tracking starts only after the scheduler is fully enabled.
> As a result, ops.init() can observe busy CPUs as idle, and those CPUs
> remain incorrectly advertised until their next idle transition.
>
> Enable built-in idle tracking before ops.init() and refresh every online
> CPU under its rq lock. Once a CPU is refreshed, later transitions keep
> its state accurate. Keep ops.update_idle() notifications disabled until
> the scheduler is fully enabled.
While a sched is being loaded, bypass mode is on and when we get out of
bypass mode, we set RENOTIFY and trigger kick each CPU, which, if the CPU
has been or is entering idle, triggers ops.update_idle(). So, BPF
implemented idle tracking gets the actual idle state update when bypass goes
off, which makes sense. Would the problem you were seeing go away if we just
clear all idle bits on load instead of setting them? The lifting of bypass
mode at the end should set idle bits for all actually idle CPUs.
Thanks.
--
tejun
next prev parent reply other threads:[~2026-08-02 19:19 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-31 18:23 [PATCHSET v3 sched_ext/for-7.3] sched_ext: Fix idle CPU state initialization and validation Andrea Righi
2026-07-31 18:23 ` [PATCH 1/2] sched_ext: Initialize idle masks before ops.init() Andrea Righi
2026-08-02 19:19 ` Tejun Heo [this message]
2026-08-03 5:46 ` Andrea Righi
2026-07-31 18:23 ` [PATCH 2/2] selftests/sched_ext: Make allowed_cpus idle validation race-free Andrea Righi
-- strict thread matches above, loose matches on Subject: below --
2026-07-31 8:59 [PATCHSET v2 sched_ext/for-7.3] sched_ext: Fix idle CPU state initialization and validation Andrea Righi
2026-07-31 8:59 ` [PATCH 1/2] sched_ext: Initialize idle masks before ops.init() Andrea Righi
2026-07-31 10:47 ` Kuba Piecuch
2026-07-31 15:01 ` Andrea Righi
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=am-YVNN5Ga12zHpM@slm.duckdns.org \
--to=tj@kernel.org \
--cc=arighi@nvidia.com \
--cc=changwoo@igalia.com \
--cc=jpiecuch@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sched-ext@lists.linux.dev \
--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.