From: Andrea Righi <arighi@nvidia.com>
To: Michal Blaszczyk <michalblk@google.com>
Cc: Tejun Heo <tj@kernel.org>, David Vernet <void@manifault.com>,
Changwoo Min <changwoo@igalia.com>,
sched-ext@lists.linux.dev, linux-kernel@vger.kernel.org,
linux-kselftest@vger.kernel.org,
Kuba Piecuch <jpiecuch@google.com>
Subject: Re: [PATCH 1/2] sched_ext: Reset runnable_at when a task leaves its scheduler
Date: Mon, 19 Oct 2026 15:51:26 +0200 [thread overview]
Message-ID: <atYgXtpPSGsoWmZE@gpd4> (raw)
In-Reply-To: <20261019124146.3582127-2-michalblk@google.com>
Hi Michal,
On Mon, Oct 19, 2026 at 12:41:45PM +0000, Michal Blaszczyk wrote:
> The watchdog measures how long a task has been waiting from
> p->scx.runnable_at, which set_task_runnable() resets when the task becomes
> runnable after it last ran. ops_dequeue() never asks for a reset, as the
> dequeue of a waiting task is temporary, e.g. for a migration or an
> attribute change.
>
> Leaving the scheduler isn't temporary. A task which is switched out of
> SCHED_EXT while it's waiting keeps its runnable_at. When it's switched back
> and becomes runnable, its wait appears to have started before it left, and
> the time it spent in another class counts towards the timeout. If the
> watchdog checks before the task runs, it aborts the scheduler:
>
> sched_ext: class_switch_stall: runner[418] failed to run for 3.010s
>
> Here, the task waited for a few milliseconds before it was switched to
> SCHED_OTHER, slept outside of SCHED_EXT for three seconds, and was charged
> for all of it as soon as it woke up on SCHED_EXT again.
>
> The same happens when scx_sub_enable_workfn() hands a waiting task over to
> a new sub-scheduler, which can then be blamed for time the task waited
> under the parent. scx_rehome_task() isn't affected, as it moves the task
> through SCX_TASK_INIT, which resets runnable_at. The stale runnable_at also
> skews the default core-sched ordering in scx_prio_less().
>
> Reset runnable_at in scx_disable_task(), when the task leaves the control
> of its scheduler.
>
> Fixes: 8a010b81b3a5 ("sched_ext: Implement runnable task stall watchdog")
> Assisted-by: LLM
> Signed-off-by: Michal Blaszczyk <michalblk@google.com>
This makes sense to me and I reproduced the issue (thanks for providing
a selftest).
Reviewed-by: Andrea Righi <arighi@nvidia.com>
-Andrea
> ---
> kernel/sched/ext/ext.c | 14 +++++++++++++-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/sched/ext/ext.c b/kernel/sched/ext/ext.c
> index 07857039aee69..120df09b9e0af 100644
> --- a/kernel/sched/ext/ext.c
> +++ b/kernel/sched/ext/ext.c
> @@ -2424,7 +2424,11 @@ static void ops_dequeue(struct rq *rq, struct task_struct *p, u64 deq_flags)
> struct scx_sched *sch = scx_task_sched(p);
> unsigned long opss;
>
> - /* dequeue is always temporary, don't reset runnable_at */
> + /*
> + * Don't reset runnable_at. If @p is waiting, the wait continues across
> + * temporary dequeues, e.g. for a migration or an attribute change.
> + * scx_disable_task() ends it if @p leaves its scheduler.
> + */
> clr_task_runnable(p, false);
>
> retry:
> @@ -4517,6 +4521,14 @@ static void scx_disable_task(struct scx_sched *sch, struct task_struct *p)
> scx_set_task_slice(p, 0);
> p->scx.reenq_cnt = 0;
>
> + /*
> + * If @p is runnable but not running, its wait started at runnable_at,
> + * which ops_dequeue() didn't reset. Leaving @sch ends the wait. Reset
> + * runnable_at the next time @p is enqueued on SCX, so that the watchdog
> + * doesn't count the time @p spends elsewhere.
> + */
> + p->scx.flags |= SCX_TASK_RESET_RUNNABLE_AT;
> +
> /*
> * Verify the task is not in BPF scheduler's custody. If flag
> * transitions are consistent, the flag should always be clear
> --
> 2.56.0.176.g3575e65682-goog
>
next prev parent reply other threads:[~2026-10-19 13:51 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-19 12:41 [PATCH 0/2] sched_ext: Reset runnable_at when a task leaves its scheduler Michal Blaszczyk
2026-10-19 12:41 ` [PATCH 1/2] " Michal Blaszczyk
2026-10-19 13:51 ` Andrea Righi [this message]
2026-10-19 22:58 ` Tejun Heo
2026-10-19 12:41 ` [PATCH 2/2] selftests/sched_ext: Add class_switch_stall test Michal Blaszczyk
2026-10-19 13:54 ` 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=atYgXtpPSGsoWmZE@gpd4 \
--to=arighi@nvidia.com \
--cc=changwoo@igalia.com \
--cc=jpiecuch@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=michalblk@google.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.