All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Usama Arif <usama.arif@linux.dev>
Cc: arighi@nvidia.com, bsegall@google.com, changwoo@igalia.com,
	dietmar.eggemann@arm.com, etsal@meta.com, juri.lelli@redhat.com,
	kprateek.nayak@amd.com, linux-kernel@vger.kernel.org,
	mgorman@suse.de, mingo@redhat.com, peterz@infradead.org,
	rostedt@goodmis.org, sched-ext@lists.linux.dev, tj@kernel.org,
	vincent.guittot@linaro.org, void@manifault.com,
	vschneid@redhat.com, yphbchou0911@gmail.com,
	emil@etsalapatis.com, david.dai@linux.dev
Subject: Re: [PATCH] sched_ext: Avoid relocking DSQ during remote consumption
Date: Wed, 23 Sep 2026 08:59:15 -1000	[thread overview]
Message-ID: <15d491d4d4fb481941e8495d48b5c610@kernel.org> (raw)
In-Reply-To: <20260923140750.2128382-1-usama.arif@linux.dev>

Applied to sched_ext/for-7.4 with an unnecessary line break removed.

Possible follow-ups:

- The !dsq branch comment in scx_dispatch_dequeue() only mentions direct
  dispatch as a source of holding_cpu. Remote consume now reaches it too.
  Can you update the comment? The dsq branch comment also names
  dispatch_to_local_dsq() as the racer when it's
  unlink_dsq_and_switch_rq_lock().

- The remote local DSQ branch of move_task_between_dsqs() has the same
  relock. Calling dispatch_dequeue_locked() before dropping src_dsq->lock
  would avoid it. scx_bpf_dsq_move() isn't widely used, but it'd still be
  nice.

Thanks.

--
tejun

      reply	other threads:[~2026-09-23 18:59 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-23 14:07 [PATCH] sched_ext: Avoid relocking DSQ during remote consumption Usama Arif
2026-09-23 18:59 ` 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=15d491d4d4fb481941e8495d48b5c610@kernel.org \
    --to=tj@kernel.org \
    --cc=arighi@nvidia.com \
    --cc=bsegall@google.com \
    --cc=changwoo@igalia.com \
    --cc=david.dai@linux.dev \
    --cc=dietmar.eggemann@arm.com \
    --cc=emil@etsalapatis.com \
    --cc=etsal@meta.com \
    --cc=juri.lelli@redhat.com \
    --cc=kprateek.nayak@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=sched-ext@lists.linux.dev \
    --cc=usama.arif@linux.dev \
    --cc=vincent.guittot@linaro.org \
    --cc=void@manifault.com \
    --cc=vschneid@redhat.com \
    --cc=yphbchou0911@gmail.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.