All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrea Righi <arighi@nvidia.com>
To: cjian720 <cjian720@163.com>
Cc: tj@kernel.org, void@manifault.com, changwoo@igalia.com,
	mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com,
	vincent.guittot@linaro.org, dietmar.eggemann@arm.com,
	rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de,
	vschneid@redhat.com, kprateek.nayak@amd.com,
	sched-ext@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: Re: [PATCH] sched_ext:SCX is preemptible by the Fair scheduler
Date: Fri, 12 Jun 2026 20:18:33 +0200	[thread overview]
Message-ID: <aixNeeZPeGlH-yQq@gpd4> (raw)
In-Reply-To: <4a81ba55.9be4.19ebce4727a.Coremail.cjian720@163.com>

On Sat, Jun 13, 2026 at 01:32:28AM +0800, cjian720 wrote:
> Hi Andrea, While this callback will be phased out eventually, SCX is still a relatively new scheduling framework. Incomplete preemption reason enums make it hard to analyze interactions between different schedulers, and filling this gap greatly boosts observability for existing SCX workloads. This patch does not touch core scheduling logic, carries zero performance overhead, and adds negligible long-term maintenance cost. 

You can get the same information directly from BPF using the sched_switch
tracepoint and looking at prev->sched_class and next->sched_class. As I
mentioned, ops.cpu_release() is a deprecated API, so I don't see much value
updating/improving it.

Thanks,
-Andrea

      parent reply	other threads:[~2026-06-12 18:18 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-12 16:14 [PATCH] sched_ext:SCX is preemptible by the Fair scheduler Cui Jian
2026-06-12 16:28 ` sashiko-bot
2026-06-12 16:32 ` Andrea Righi
     [not found]   ` <4a81ba55.9be4.19ebce4727a.Coremail.cjian720@163.com>
2026-06-12 18:18     ` Andrea Righi [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=aixNeeZPeGlH-yQq@gpd4 \
    --to=arighi@nvidia.com \
    --cc=bsegall@google.com \
    --cc=changwoo@igalia.com \
    --cc=cjian720@163.com \
    --cc=dietmar.eggemann@arm.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=tj@kernel.org \
    --cc=vincent.guittot@linaro.org \
    --cc=void@manifault.com \
    --cc=vschneid@redhat.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.