From: Andrea Righi <andrea.righi@linux.dev>
To: Tejun Heo <tj@kernel.org>
Cc: void@manifault.com, peterz@infradead.org, mingo@redhat.com,
kernel-team@meta.com, linux-kernel@vger.kernel.org,
sched-ext@meta.com, Daniel Hodges <hodges.daniel.scott@gmail.com>,
Changwoo Min <multics69@gmail.com>,
Dan Schatzberg <schatzberg.dan@gmail.com>
Subject: Re: [PATCH 3/3] sched_ext, scx_qmap: Add and use SCX_ENQ_CPU_SELECTED
Date: Sat, 28 Sep 2024 15:21:46 +0200 [thread overview]
Message-ID: <ZvgC6rhPCxXYTrh6@gpd3> (raw)
In-Reply-To: <20240927234838.152112-4-tj@kernel.org>
On Fri, Sep 27, 2024 at 01:46:13PM -1000, Tejun Heo wrote:
> scx_qmap and other schedulers in the SCX repo are using SCX_ENQ_WAKEUP to
> tell whether ops.select_cpu() was called. This is incorrect as
> ops.select_cpu() can be skipped in the wakeup path and leads to e.g.
> incorrectly skipping direct dispatch for tasks that are bound to a single
> CPU.
>
> sched core has been udpated to specify ENQUEUE_RQ_SELECTED if
> ->select_task_rq() was called. Map it to SCX_ENQ_CPU_SELECTED and update
> scx_qmap to test it instead of SCX_ENQ_WAKEUP.
Even if it's quite convenient to have the SCX_ENQ_CPU_SELECTED flag
provided by kernel, I was wondering if we could just delegate this whole
logic to BPF and avoid introducing this extra flag in the kernel.
In theory we could track when ops.select_cpu() is called by setting a
flag in the BPF task context (BPF_MAP_TYPE_TASK_STORAGE). Specifically,
the flag could be set in ops.select_cpu() and cleared in ops.stopping().
Then, when ops.enqueue() is called, we can check the flag to determine
whether ops.select_cpu() was skipped or not.
Since most of the scx schedulers already implement their own task
context, this shouldn't add too much complexity/overhead to the BPF
code, it'd be fully backward-compatible and it doesn't depend on the
particular kernel logic that calls ->select_task_rq(). WDYT?
Thanks,
-Andrea
>
> Signed-off-by: Tejun Heo <tj@kernel.org>
> Cc: David Vernet <void@manifault.com>
> Cc: Daniel Hodges <hodges.daniel.scott@gmail.com>
> Cc: Changwoo Min <multics69@gmail.com>
> Cc: Andrea Righi <andrea.righi@linux.dev>
> Cc: Dan Schatzberg <schatzberg.dan@gmail.com>
> ---
> kernel/sched/ext.c | 1 +
> tools/sched_ext/scx_qmap.bpf.c | 4 ++--
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/sched/ext.c b/kernel/sched/ext.c
> index c09e3dc38c34..9f00c8b629f1 100644
> --- a/kernel/sched/ext.c
> +++ b/kernel/sched/ext.c
> @@ -691,6 +691,7 @@ enum scx_enq_flags {
> /* expose select ENQUEUE_* flags as enums */
> SCX_ENQ_WAKEUP = ENQUEUE_WAKEUP,
> SCX_ENQ_HEAD = ENQUEUE_HEAD,
> + SCX_ENQ_CPU_SELECTED = ENQUEUE_RQ_SELECTED,
>
> /* high 32bits are SCX specific */
>
> diff --git a/tools/sched_ext/scx_qmap.bpf.c b/tools/sched_ext/scx_qmap.bpf.c
> index 83c8f54c1e31..588b7dce44fa 100644
> --- a/tools/sched_ext/scx_qmap.bpf.c
> +++ b/tools/sched_ext/scx_qmap.bpf.c
> @@ -230,8 +230,8 @@ void BPF_STRUCT_OPS(qmap_enqueue, struct task_struct *p, u64 enq_flags)
> return;
> }
>
> - /* if !WAKEUP, select_cpu() wasn't called, try direct dispatch */
> - if (!(enq_flags & SCX_ENQ_WAKEUP) &&
> + /* if select_cpu() wasn't called, try direct dispatch */
> + if (!(enq_flags & SCX_ENQ_CPU_SELECTED) &&
> (cpu = pick_direct_dispatch_cpu(p, scx_bpf_task_cpu(p))) >= 0) {
> __sync_fetch_and_add(&nr_ddsp_from_enq, 1);
> scx_bpf_dispatch(p, SCX_DSQ_LOCAL_ON | cpu, slice_ns, enq_flags);
> --
> 2.46.2
>
next prev parent reply other threads:[~2024-09-28 13:21 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-27 23:46 [PATCHSET sched/urgent, sched_ext/for-6.12-fixes] sched/core, sched_ext: Add ENQUEUE_RQ_SELECTED to fix ->select_task_rq() skip detection in sched_ext schedulers Tejun Heo
2024-09-27 23:46 ` [PATCH 1/3] sched/core: Make select_task_rq() take the pointer to wake_flags instead of value Tejun Heo
2024-09-28 0:38 ` David Vernet
2024-09-27 23:46 ` [PATCH 2/3] sched/core: Add ENQUEUE_RQ_SELECTED to indicate whether ->select_task_rq() was called Tejun Heo
2024-09-28 0:38 ` David Vernet
2024-10-01 20:12 ` Tejun Heo
2024-10-04 20:14 ` Tejun Heo
2024-10-05 9:38 ` Peter Zijlstra
2024-10-07 16:44 ` Tejun Heo
2024-09-27 23:46 ` [PATCH 3/3] sched_ext, scx_qmap: Add and use SCX_ENQ_CPU_SELECTED Tejun Heo
2024-09-28 0:39 ` David Vernet
2024-09-28 13:21 ` Andrea Righi [this message]
2024-09-28 16:52 ` Tejun Heo
2024-10-07 20:20 ` [PATCHSET sched/urgent, sched_ext/for-6.12-fixes] sched/core, sched_ext: Add ENQUEUE_RQ_SELECTED to fix ->select_task_rq() skip detection in sched_ext schedulers Tejun Heo
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=ZvgC6rhPCxXYTrh6@gpd3 \
--to=andrea.righi@linux.dev \
--cc=hodges.daniel.scott@gmail.com \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=multics69@gmail.com \
--cc=peterz@infradead.org \
--cc=schatzberg.dan@gmail.com \
--cc=sched-ext@meta.com \
--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.