All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Andrea Righi <arighi@nvidia.com>
Cc: David Vernet <void@manifault.com>,
	Changwoo Min <changwoo@igalia.com>,
	John Stultz <jstultz@google.com>,
	sched-ext@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 sched_ext/for-7.4] sched_ext: Keep proxy donors with slice left on the local DSQ
Date: Fri, 09 Oct 2026 13:01:55 -1000	[thread overview]
Message-ID: <61e309273c68312c1c68e3da2ea45394@kernel.org> (raw)
In-Reply-To: <20261009200827.4026499-1-arighi@nvidia.com>

Hello, Andrea.

On Fri, Oct 09, 2026 at 10:08:26PM +0200, Andrea Righi wrote:
> 		if ((p->scx.slice || unlikely(p == scx_rescuee(rq))) &&
> 		    !scx_bypassing(sch, cpu_of(rq))) {
> -			if (p->scx.flags & SCX_TASK_IMMED) {
> +			if ((p->scx.flags & SCX_TASK_IMMED) && !proxy_put) {

The bypassing test skips the keep for a proxy_put as well, so under bypass
the put falls through to the ENQ_LAST branch with idle as @next, and the
WARN there fires for an ENQ_BLOCKED scheduler without ENQ_LAST. Every
blocked donor picked during enable or disable and put back by
proxy_resched_idle() takes that path; the base tree's blocked-donor block
never reached it. Reproduced on a 16-CPU VM with pipe mutex contention
while cycling scx_qmap -X, the first disable trips it on three CPUs:

  WARNING: kernel/sched/ext/ext.c:3607 at put_prev_task_scx+0x743/0x870, CPU#5: pipe-contend/2042
  Sched_ext: qmap (disabling), task: runnable_at=+0ms
  Call Trace:
   proxy_resched_idle+0x51/0x120
   __schedule+0x3f1/0x1900
   schedule+0xae/0x100
   schedule_preempt_disabled+0x12/0x20
   __mutex_lock+0x4d6/0xc20
   anon_pipe_write+0xa0/0x650

The same branch is also reachable without bypass if an out-of-band slice
write zeroes a non-running donor's slice before the bookkeeping put.

> +					/* SCX_ENQ_IMMED uses SCX_CAP_ENQ_IMMED, the base cap. */
> +					if (proxy_put && (p->scx.flags & SCX_TASK_IMMED))
> +						enq_flags |= SCX_ENQ_IMMED;

Not from this patch, but noticed while going through it: this insert runs
with rq->next_class still ext, and proxy_resched_idle() then lowers it to
idle with the IMMED donor on the local DSQ. A higher class waking on the
CPU before the re-pick hits the idle class's wakeup_preempt() rather than
wakeup_preempt_scx(), so nothing reenqueues the donor and it sits behind
the new task. The scan dsq_inc_nr() queued only helps if it runs after that
wakeup. proxy_resched_idle() never looked at the local DSQ, but with this
patch that's the regular state after every IMMED donor's bookkeeping put.

The SCX_ENQ_IMMED comment in internal.h describes v2: in v3 an IMMED donor
stays local only for the bookkeeping put and is reenqueued on preemption or
by the deferred scan like any other IMMED task. The dispatch_one() addition
about a blocked IMMED donor making the scan a no-op comes from v2's
exemption in local_task_should_reenq() too, and the dsq_inc_nr() and
local_task_should_reenq() comment changes don't go with anything in v3.

Thanks.

-- 
tejun

      reply	other threads:[~2026-10-09 23:01 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-09 20:08 [PATCH v3 sched_ext/for-7.4] sched_ext: Keep proxy donors with slice left on the local DSQ Andrea Righi
2026-10-09 23:01 ` Tejun Heo [this message]

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=61e309273c68312c1c68e3da2ea45394@kernel.org \
    --to=tj@kernel.org \
    --cc=arighi@nvidia.com \
    --cc=changwoo@igalia.com \
    --cc=jstultz@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.