From: Hui Su <sh_def@163.com>
To: sh_def@163.com
Cc: arighi@nvidia.com, bsegall@google.com, changwoo@igalia.com,
connoro@google.com, dietmar.eggemann@arm.com, jstultz@google.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, tim.c.chen@linux.intel.com,
tj@kernel.org, vincent.guittot@linaro.org, void@manifault.com,
vschneid@redhat.com, yu.c.chen@intel.com
Subject: Re: [PATCH v4 1/5] sched: Dispatch task ticks for donor and execution classes
Date: Wed, 9 Sep 2026 19:42:51 +0900 [thread overview]
Message-ID: <20260909104251.3131056-1-sh_def@163.com> (raw)
In-Reply-To: <20260909092901.2989564-2-sh_def@163.com>
On Tue, Sep 09, 2026, Sashiko AI review wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential
> issue(s) to consider:
>
> - ## [High] Infinite timeslice and preemption bypass during SCX proxy
> execution due to a mismatch between slice decrement (execution context)
> and slice checking (scheduling context).
>
> commit ff57ff4a11692a1b0d98a6cd57257eb58a1bd864
> Author: Hui Su <sh_def@163.com>
>
> Does this cause an infinite timeslice for SCX tasks during proxy execution?
>
> When an SCX task acts as a donor in proxy execution, task_tick_scx() sets
> curr to rq->donor. However, update_curr_scx() applies the slice decrement
> to the execution context (rq->curr):
>
> static void update_curr_scx(struct rq *rq)
> {
> struct task_struct *curr = rq->curr;
> ...
> if (curr->scx.slice != SCX_SLICE_INF)
> curr->scx.slice -= min_t(u64, curr->scx.slice, delta_exec);
> ...
> }
>
> Later in task_tick_scx(), the slice check is performed against the donor
> task which was never decremented:
>
> if (!curr->scx.slice)
> resched_curr(rq);
>
> Since the donor's slice doesn't decrease, it will never hit zero, meaning
> resched_curr(rq) is bypassed indefinitely.
>
> Additionally, if the proxy task is SCX but the donor is not,
> task_tick_scx() returns early here because the donor is not an SCX task,
> skipping the SCX tick processing completely. Should the slice management
> be explicitly tied to the execution context rather than the donor?
>
> --
> Sashiko AI review
Thanks for the report.
This configuration is currently unreachable. CONFIG_SCHED_PROXY_EXEC
depends on !SCHED_CLASS_EXT, so sched_ext and proxy execution cannot be
enabled together.
When CONFIG_SCHED_CLASS_EXT=y, proxy execution is disabled and rq->donor
and rq->curr alias the same task. Therefore task_tick_scx() using
rq->donor and update_curr_scx() using rq->curr still operate on the same
task, and the slice decrement and check cannot diverge.
The sched_ext change in this patch only adapts it to the new task_tick()
interface for the currently supported configuration.
If sched_ext and proxy execution are made compatible in the future, the
SCX donor/execution-context ownership will need to be handled as part of
that integration.
Thanks,
Hui
next prev parent reply other threads:[~2026-09-09 10:44 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-09 9:28 [PATCH v4 0/5] sched: Handle split scheduling and execution contexts in task ticks Hui Su
2026-09-09 9:28 ` [PATCH v4 1/5] sched: Dispatch task ticks for donor and execution classes Hui Su
2026-09-09 10:42 ` Hui Su [this message]
2026-09-09 17:43 ` Andrea Righi
2026-09-10 10:49 ` Hui Su
2026-09-09 9:28 ` [PATCH v4 2/5] sched/numa: Drive NUMA task tick from execution context Hui Su
2026-09-09 9:28 ` [PATCH v4 3/5] sched/cache: Drive cache " Hui Su
2026-09-09 11:03 ` Peter Zijlstra
2026-09-10 10:53 ` Hui Su
2026-09-09 9:29 ` [PATCH v4 4/5] sched/rt: Fix RT watchdog accounting for proxy execution Hui Su
2026-09-09 11:04 ` Peter Zijlstra
2026-09-10 10:54 ` Hui Su
2026-09-12 17:30 ` Hui Su
2026-09-09 9:29 ` [PATCH v4 5/5] sched/core: Fix donor slice accounting under " Hui Su
2026-09-10 10:55 ` Hui Su
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=20260909104251.3131056-1-sh_def@163.com \
--to=sh_def@163.com \
--cc=arighi@nvidia.com \
--cc=bsegall@google.com \
--cc=changwoo@igalia.com \
--cc=connoro@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=jstultz@google.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=tim.c.chen@linux.intel.com \
--cc=tj@kernel.org \
--cc=vincent.guittot@linaro.org \
--cc=void@manifault.com \
--cc=vschneid@redhat.com \
--cc=yu.c.chen@intel.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®