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 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.