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 2/2] selftests/sched_ext: Add class_switch_stall test
Date: Mon, 19 Oct 2026 15:54:38 +0200 [thread overview]
Message-ID: <atYhHvJAxLp01QbT@gpd4> (raw)
In-Reply-To: <20261019124146.3582127-3-michalblk@google.com>
Hi Michal,
On Mon, Oct 19, 2026 at 12:41:46PM +0000, Michal Blaszczyk wrote:
> Add a test for a task which leaves SCHED_EXT while it's waiting. Its
> scheduler keeps the task waiting on a DSQ after it wakes up. The test
> switches the task to SCHED_OTHER while it's waiting, lets it sleep outside
> of SCHED_EXT for three times the watchdog timeout, then switches it back
> and wakes it up. The scheduler keeps it waiting again, for longer than the
> watchdog interval but shorter than the timeout, which the watchdog must not
> report as a stall.
>
> Without the previous patch, the watchdog charges the task for the time it
> spent outside of SCHED_EXT and aborts the scheduler.
>
> Assisted-by: LLM
> Signed-off-by: Michal Blaszczyk <michalblk@google.com>
...
> diff --git a/tools/testing/selftests/sched_ext/class_switch_stall.c b/tools/testing/selftests/sched_ext/class_switch_stall.c
> new file mode 100644
> index 0000000000000..489d23c777f05
> --- /dev/null
> +++ b/tools/testing/selftests/sched_ext/class_switch_stall.c
> @@ -0,0 +1,240 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Check that a task which leaves SCHED_EXT while it's waiting doesn't carry
> + * that wait over to its next stay on SCHED_EXT. If it did, the watchdog would
> + * count the time the task spent outside SCHED_EXT as waiting and abort the
> + * scheduler.
> + *
> + * Copyright (c) 2026 Google LLC.
> + */
> +#define _GNU_SOURCE
> +
> +#include <bpf/bpf.h>
> +#include <poll.h>
> +#include <sched.h>
> +#include <scx/common.h>
> +#include <signal.h>
> +#include <stdio.h>
> +#include <string.h>
> +#include <sys/wait.h>
> +#include <unistd.h>
> +#include "class_switch_stall.bpf.skel.h"
> +#include "scx_test.h"
> +
> +#ifndef SCHED_EXT
> +#define SCHED_EXT 7
> +#endif
> +
> +/* class_switch_stall_ops.timeout_ms, the watchdog checks every half of it */
> +#define TIMEOUT_MS 1000
> +/* longer than the watchdog interval, but shorter than the timeout */
> +#define PARK_MS 750
> +/* time spent outside of SCHED_EXT, a stale wait would exceed the timeout */
> +#define OUTSIDE_MS (3 * TIMEOUT_MS)
Could we increase the watchdog timeout to 3s and the park duration to
2s, updating timeout_ms accordingly?
With the current values, there is only about 250ms of headroom for timer
delivery, dispatch, and the child actually getting CPU time before it
becomes eligible for a watchdog stall The first phase also depends on
userspace switching the parked child out within 1s.
I haven't observed a false failure, so this is a robustness suggestion
(I'm thinking at loaded CI VMs) rather than an observed problem. A 2s
park would still span the nominal 1.5s watchdog interval while leaving
more headroom.
Thanks,
-Andrea
prev parent reply other threads:[~2026-10-19 13:54 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
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 [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=atYhHvJAxLp01QbT@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox