mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: sched-ext@lists.linux.dev
Cc: David Vernet <void@manifault.com>,
	Andrea Righi <arighi@nvidia.com>,
	Changwoo Min <changwoo@igalia.com>,
	Emil Tsalapatis <emil@etsalapatis.com>,
	David Dai <david.dai@linux.dev>,
	linux-kernel@vger.kernel.org, Tejun Heo <tj@kernel.org>
Subject: [PATCHSET sched_ext/for-7.4] sched_ext: Report a sub-scheduler's attach-time ecaps before lifting its enable bypass
Date: Thu,  8 Oct 2026 23:43:54 -1000	[thread overview]
Message-ID: <20261009094356.2852794-1-tj@kernel.org> (raw)

Hello,

A sub-scheduler learns which cids it holds through ops.sub_ecaps_updated(),
but the grants its parent makes when it attaches are reported only after its
enable bypass is lifted, which is also when its tasks are handed to it. So
it gets its first ops.enqueue() calls before it has been notified of a
single cid and has to hold the tasks somewhere until the grants arrive.

Patch 1 factors the per-cpu ecaps sync out of the dispatch-side drain so
that it can run from elsewhere. Patch 2 has the enable path report the
attach-time grants on every cpu while the sub-scheduler is still bypassing,
so that it has its complete cid view when the first task arrives.

Verified with a sub-scheduler attaching under a parent with tasks already
queued, with cids revoked and granted back while attached, and across detach
and re-attach: no task is rescued or stalled at attach, and the root
scheduler is unaffected. The ordering between the enable path, the per-cpu
syncs and the parent's grants was model-checked with TLC.

Based on sched_ext/for-7.4 (3d7c2f550eef).

This patchset contains the following 2 patches.

 0001 sched_ext: Factor out sync_pcpu_ecaps()
 0002 sched_ext: Report a sub-scheduler's attach-time ecaps before lifting its enable bypass

The patchset is also available in the following git branch:

 git://git.kernel.org/pub/scm/linux/kernel/git/tj/sched_ext.git sub-attach-ecaps

diffstat follows. Thanks.

 kernel/sched/ext/sub.c | 194 ++++++++++++++++++++++++++++++++++---------------
 1 file changed, 134 insertions(+), 60 deletions(-)

--
tejun

             reply	other threads:[~2026-10-09  9:43 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-09  9:43 Tejun Heo [this message]
2026-10-09  9:43 ` [PATCH 1/2] sched_ext: Factor out sync_pcpu_ecaps() Tejun Heo
2026-10-09  9:43 ` [PATCH 2/2] sched_ext: Report a sub-scheduler's attach-time ecaps before lifting its enable bypass 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=20261009094356.2852794-1-tj@kernel.org \
    --to=tj@kernel.org \
    --cc=arighi@nvidia.com \
    --cc=changwoo@igalia.com \
    --cc=david.dai@linux.dev \
    --cc=emil@etsalapatis.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®