From: Andrea Righi <arighi@nvidia.com>
To: Tejun Heo <tj@kernel.org>
Cc: David Vernet <void@manifault.com>,
Changwoo Min <changwoo@igalia.com>,
Emil Tsalapatis <emil@etsalapatis.com>,
sched-ext@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH sched_ext/for-7.1] tools/sched_ext: Kick idle CPU for pinned tasks in scx_qmap
Date: Sat, 11 Apr 2026 17:03:04 +0200 [thread overview]
Message-ID: <adpiqHmu8YrxBJ78@gpd4> (raw)
In-Reply-To: <de52a1c5537e2a130d19eb244b7606c1@kernel.org>
Hi Tejun,
On Sat, Apr 11, 2026 at 01:33:56AM -1000, Tejun Heo wrote:
> scx_qmap uses global BPF queue maps for task dispatch. A task pinned to a
> single CPU can only be dispatched by its home CPU's ops.dispatch(), but an
> idle CPU won't call ops.dispatch() on its own. This leaves per-CPU kthreads
> like ksoftirqd stranded, causing NOHZ tick-stop warnings from pending
> softirqs.
>
> Kick the target CPU with SCX_KICK_IDLE when enqueueing a pinned task.
>
> Signed-off-by: Tejun Heo <tj@kernel.org>
> ---
> tools/sched_ext/scx_qmap.bpf.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/tools/sched_ext/scx_qmap.bpf.c b/tools/sched_ext/scx_qmap.bpf.c
> index f3587fb709c9..09d1624fb869 100644
> --- a/tools/sched_ext/scx_qmap.bpf.c
> +++ b/tools/sched_ext/scx_qmap.bpf.c
> @@ -314,6 +314,14 @@ void BPF_STRUCT_OPS(qmap_enqueue, struct task_struct *p, u64 enq_flags)
> __sync_fetch_and_add(&nr_highpri_queued, 1);
> }
> __sync_fetch_and_add(&nr_enqueued, 1);
> +
> + /*
> + * Kick idle target CPU for pinned tasks. Without this, the CPU can
> + * idle while ksoftirqd is pending in the BPF queue, triggering NOHZ
> + * tick-stop warnings.
> + */
> + if (p->nr_cpus_allowed == 1)
> + scx_bpf_kick_cpu(scx_bpf_task_cpu(p), SCX_KICK_IDLE);
I think we should kick the task's CPU in general, also when
p->nr_cpus_allowed == N, with N < nr_cpus_ids, otherwise we can have the same
problem if one of the N allowed CPUs is never awakened. Moreover, tasks will
have a better chance to keep running on the same CPU, which is nice, unless we
want to limit the amount of CPU wakeups.
If we want to be fancy we could even do something like this:
if (!__COMPAT_is_enq_cpu_selected(enq_flags) && !scx_bpf_task_running(p))
scx_bpf_kick_cpu(scx_bpf_task_cpu(p), SCX_KICK_IDLE);
In practice: if ops.select_cpu() was called there's no reason to do the kick,
because it's supposed to be done already in ops.select_cpu(). Simiarly, if we've
a queued wakeup event, ops.select_cpu() was skipped, so we should explicitly
kick the CPU if the task was enqueued and it wasn't running already.
Thanks,
-Andrea
prev parent reply other threads:[~2026-04-11 15:03 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-11 11:33 [PATCH sched_ext/for-7.1] tools/sched_ext: Kick idle CPU for pinned tasks in scx_qmap Tejun Heo
2026-04-11 12:57 ` Cheng-Yang Chou
2026-04-11 14:27 ` Cheng-Yang Chou
2026-04-11 15:03 ` 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=adpiqHmu8YrxBJ78@gpd4 \
--to=arighi@nvidia.com \
--cc=changwoo@igalia.com \
--cc=emil@etsalapatis.com \
--cc=linux-kernel@vger.kernel.org \
--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