All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Tejun Heo <tj@kernel.org>
Cc: David Vernet <void@manifault.com>,
	Andrea Righi <andrea.righi@linux.dev>,
	Changwoo Min <changwoo@igalia.com>,
	linux-kernel@vger.kernel.org, sched-ext@lists.linux.dev,
	Wen-Fang Liu <liuwenfang@honor.com>
Subject: Re: [PATCH 3/3] sched_ext: Allow scx_bpf_reenqueue_local() to be called from anywhere
Date: Mon, 27 Oct 2025 10:18:22 +0100	[thread overview]
Message-ID: <20251027091822.GH3245006@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <20251025001849.1915635-4-tj@kernel.org>

On Fri, Oct 24, 2025 at 02:18:49PM -1000, Tejun Heo wrote:
> The ops.cpu_acquire/release() callbacks are broken - they miss events under
> multiple conditions and can't be fixed without adding global sched core hooks
> that sched maintainers don't want. They also aren't necessary as BPF schedulers
> can use generic BPF mechanisms like tracepoints to achieve the same goals.
> 
> The main use case for cpu_release() was calling scx_bpf_reenqueue_local() when
> a CPU gets preempted by a higher priority scheduling class. However, the old
> scx_bpf_reenqueue_local() could only be called from cpu_release() context.

I'm a little confused. Isn't this the problem where balance_one()
migrates a task to the local rq and we end up having to RETRY_TASK
because another (higher) rq gets modified?

Why can't we simply re-queue the task in the RETRY_TASK branch --
effectively undoing balance_one()?


Relying on hooking into tracepoints seems like a gruesome hack.

  parent reply	other threads:[~2025-10-27  9:18 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-25  0:18 [PATCHSET sched_ext/for-6.19] sched_ext: Deprecate ops.cpu_acquire/release() Tejun Heo
2025-10-25  0:18 ` [PATCH 1/3] sched_ext: Split schedule_deferred() into locked and unlocked variants Tejun Heo
2025-10-25 23:17   ` Emil Tsalapatis
2025-10-25  0:18 ` [PATCH 2/3] sched_ext: Factor out reenq_local() from scx_bpf_reenqueue_local() Tejun Heo
2025-10-25 23:19   ` Emil Tsalapatis
2025-10-25  0:18 ` [PATCH 3/3] sched_ext: Allow scx_bpf_reenqueue_local() to be called from anywhere Tejun Heo
2025-10-25 23:21   ` Emil Tsalapatis
2025-10-27  9:18   ` Peter Zijlstra [this message]
2025-10-27 16:00     ` Tejun Heo
2025-10-27 17:49       ` Peter Zijlstra
2025-10-27 18:05         ` Tejun Heo
2025-10-27 18:07           ` Peter Zijlstra
2025-10-27 18:10       ` Peter Zijlstra
2025-10-27 18:17         ` Tejun Heo
2025-10-28 11:01           ` Peter Zijlstra
2025-10-28 17:07             ` Tejun Heo
2025-10-27 18:19   ` [PATCH v2 " Tejun Heo
2025-10-29 10:45     ` Peter Zijlstra
2025-10-29 15:11       ` Tejun Heo
2025-10-29 15:49     ` [PATCH v3 " Tejun Heo
2025-11-27 10:39       ` Kuba Piecuch
2025-12-02 23:05         ` Tejun Heo
2025-12-11 14:24       ` Kuba Piecuch
2025-12-11 16:17         ` Tejun Heo
2025-12-11 16:20           ` Tejun Heo
2025-12-13  1:16             ` Andrea Righi
2025-12-13  1:18               ` Tejun Heo
2025-10-29 15:31 ` [PATCHSET sched_ext/for-6.19] sched_ext: Deprecate ops.cpu_acquire/release() 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=20251027091822.GH3245006@noisy.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=andrea.righi@linux.dev \
    --cc=changwoo@igalia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=liuwenfang@honor.com \
    --cc=sched-ext@lists.linux.dev \
    --cc=tj@kernel.org \
    --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.