From: sashiko-bot@kernel.org
To: "Andrea Righi" <arighi@nvidia.com>
Cc: sched-ext@lists.linux.dev
Subject: Re: [PATCH 1/2] sched_ext: Enable tick for finite slices on nohz_full
Date: Mon, 06 Jul 2026 16:49:24 +0000 [thread overview]
Message-ID: <20260706164925.C85BA1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260706162819.650155-2-arighi@nvidia.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
New issues:
- [High] The patch's fix for finite slices is incomplete: it fails to restore the tick dependency when switching from a tick-stopped non-EXT task (such as idle) to an EXT task with a finite slice, if the last EXT task on that CPU also had a finite slice.
Pre-existing issues:
- [High] The patch manually sets the tick dependency when transitioning to a finite-slice SCX task but fails to ensure it is cleared when transitioning out to a non-EXT task (such as CFS or idle), causing a persistent leak that breaks nohz_full isolation.
- [High] When transitioning to an infinite-slice task, the patch continues to call `sched_update_tick_dependency(rq)`. Because `scx_can_stop_tick()` evaluates the outgoing task (`rq->curr`), transitioning from a non-EXT task to an infinite-slice EXT task while in bypass mode will incorrectly clear the tick dependency.
--
commit ed44446cf6110ce75b933d2ec6430b4cf1e80f2a
Author: Andrea Righi <arighi@nvidia.com>
sched_ext: Enable tick for finite slices on nohz_full
This commit addresses an issue where an incoming SCHED_EXT task with a finite
slice could fail to receive the ticks needed to expire its slice. It changes
set_next_task_scx() to directly set the TICK_DEP_BIT_SCHED dependency for
finite-slice tasks, bypassing the normal sched_update_tick_dependency() check
that relies on the outgoing task state. For infinite-slice tasks, it continues
to use sched_update_tick_dependency().
> diff --git a/kernel/sched/ext/ext.c b/kernel/sched/ext/ext.c
> index 691d53fe0f648..9b2399a1e9656 100644
> --- a/kernel/sched/ext/ext.c
> +++ b/kernel/sched/ext/ext.c
> @@ -2974,12 +2974,20 @@ static void set_next_task_scx(struct rq *rq, struct task_struct *p, bool first)
> */
> if ((p->scx.slice == SCX_SLICE_INF) !=
> (bool)(rq->scx.flags & SCX_RQ_CAN_STOP_TICK)) {
[Severity: High]
Does this condition prevent the tick dependency from being restored when
switching from a tick-stopped non-EXT task (such as idle) to an EXT task
with a finite slice, if the last EXT task on that CPU also had a finite slice?
If a finite-slice EXT task previously cleared SCX_RQ_CAN_STOP_TICK, and the
CPU then transitions to a non-EXT state that clears the global tick dependency,
the false != false evaluation here will bypass this entire block. This would
cause the new finite-slice EXT task to run without a tick, potentially causing
it to monopolize the CPU since its slice won't expire.
> - if (p->scx.slice == SCX_SLICE_INF)
> + if (p->scx.slice == SCX_SLICE_INF) {
> rq->scx.flags |= SCX_RQ_CAN_STOP_TICK;
> - else
> + sched_update_tick_dependency(rq);
[Severity: High]
This isn't a bug introduced by this patch, but when transitioning from a
non-EXT task to an infinite-slice EXT task while in bypass mode, could calling
sched_update_tick_dependency() here incorrectly clear the tick dependency?
Because scx_can_stop_tick() evaluates the outgoing task:
kernel/sched/ext/ext.c:scx_can_stop_tick() {
...
if (p->sched_class != &ext_sched_class)
return true;
...
}
It will return true early for the outgoing non-EXT task. This bypasses the
scx_bypassing() check entirely, which could stall tasks queued in the bypass
DSQ indefinitely by incorrectly stopping the scheduler tick.
> + } else {
> rq->scx.flags &= ~SCX_RQ_CAN_STOP_TICK;
>
> - sched_update_tick_dependency(rq);
> + /*
> + * The rq still references the outgoing scheduling context.
> + * A finite slice is sufficient by itself to require the tick.
> + */
> + if (tick_nohz_full_cpu(cpu_of(rq)))
> + tick_nohz_dep_set_cpu(cpu_of(rq),
> + TICK_DEP_BIT_SCHED);
[Severity: High]
This is a pre-existing issue, but does setting the tick dependency here leave a
persistent leak when the task exits the SCX class?
When an EXT task with a finite slice blocks or exits on a nohz_full CPU,
dequeue_task() calls sub_nr_running(), which invokes
sched_update_tick_dependency(). At that moment, __schedule() hasn't updated
rq->curr, so scx_can_stop_tick() evaluates the outgoing finite-slice EXT
task and returns false.
This leaves the tick dependency set. Subsequent transitions to non-EXT tasks
like idle or CFS do not re-evaluate or clear this dependency, meaning the tick
could run persistently on a nohz_full CPU, breaking isolation.
> + }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260706162819.650155-1-arighi@nvidia.com?part=1
next prev parent reply other threads:[~2026-07-06 16:49 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-06 16:18 [PATCHSET sched_ext/for-7.2-fixes] sched_ext: Fix finite-slice ticks on nohz_full Andrea Righi
2026-07-06 16:18 ` [PATCH 1/2] sched_ext: Enable tick for finite slices " Andrea Righi
2026-07-06 16:49 ` sashiko-bot [this message]
2026-07-06 22:09 ` Tejun Heo
2026-07-07 5:52 ` Andrea Righi
2026-07-06 16:18 ` [PATCH 2/2] selftests/sched_ext: Verify nohz_full tick behavior Andrea Righi
2026-07-06 16:37 ` sashiko-bot
-- strict thread matches above, loose matches on Subject: below --
2026-07-07 8:17 [PATCHSET v2 sched_ext/for-7.2-fixes] sched_ext: Fix finite-slice ticks on nohz_full Andrea Righi
2026-07-07 8:17 ` [PATCH 1/2] sched_ext: Enable tick for finite slices " Andrea Righi
2026-07-07 20:56 ` Tejun Heo
2026-07-08 7:46 [PATCHSET v3 sched_ext/for-7.2-fixes] sched_ext: Fix finite-slice ticks " Andrea Righi
2026-07-08 7:46 ` [PATCH 1/2] sched_ext: Enable tick for finite slices " Andrea Righi
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=20260706164925.C85BA1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=arighi@nvidia.com \
--cc=sashiko-reviews@lists.linux.dev \
--cc=sched-ext@lists.linux.dev \
/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.