From: Andrea Righi <arighi@nvidia.com>
To: Changwoo Min <changwoo@igalia.com>
Cc: Tejun Heo <tj@kernel.org>, David Vernet <void@manifault.com>,
bpf@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 6/8] sched_ext: idle: Introduce scx_bpf_select_cpu_and()
Date: Sat, 15 Mar 2025 10:08:28 +0100 [thread overview]
Message-ID: <Z9VDjLzd8CA-Xf9N@gpd3> (raw)
In-Reply-To: <b350d05c-3279-4d62-86fe-555ef0985f03@igalia.com>
Hi Changwoo,
On Sat, Mar 15, 2025 at 10:35:03AM +0900, Changwoo Min wrote:
> Hi Andrea,
...
> > +/**
> > + * scx_bpf_select_cpu_and - Pick an idle CPU usable by task @p,
> > + * prioritizing those in @cpus_allowed
> > + * @p: task_struct to select a CPU for
> > + * @prev_cpu: CPU @p was on previously
> > + * @wake_flags: %SCX_WAKE_* flags
> > + * @cpus_allowed: cpumask of allowed CPUs
> > + * @flags: %SCX_PICK_IDLE* flags
> > + *
> > + * Can only be called from ops.select_cpu() if the built-in CPU selection is
> > + * enabled - ops.update_idle() is missing or %SCX_OPS_KEEP_BUILTIN_IDLE is set.
> > + * @p, @prev_cpu and @wake_flags match ops.select_cpu().
>
> I think that scx_bpf_select_cpu_and () needs to be allowed to
> call from ops.enqueue(). That is because many scx schedulers have
> some logic similar to scx_bpf_select_cpu_dfl() to kick an idle
> CPU proactively.
That's a valid point, it can be a good opportunity to consolidate the logic
used in most schedulers, where the same "pick idle CPU" function is called
from both ops.select_cpu() and ops.enqueue() and have a unified core API
usable from both contexts.
I'll extend the scope of this kfunc to include ops.enqueue() in the next
version and run some tests with it.
Thanks!
-Andrea
next prev parent reply other threads:[~2025-03-15 9:08 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-14 9:45 [PATCHSET v3 sched_ext/for-6.15] sched_ext: Enhance built-in idle selection with allowed CPUs Andrea Righi
2025-03-14 9:45 ` [PATCH 1/8] sched_ext: idle: Honor idle flags in the built-in idle selection policy Andrea Righi
2025-03-14 9:45 ` [PATCH 2/8] sched_ext: idle: Refactor scx_select_cpu_dfl() Andrea Righi
2025-03-14 18:17 ` Tejun Heo
2025-03-14 9:45 ` [PATCH 3/8] sched_ext: idle: Extend topology optimizations to all tasks Andrea Righi
2025-03-14 18:21 ` Tejun Heo
2025-03-14 20:05 ` Andrea Righi
2025-03-14 9:45 ` [PATCH 4/8] sched_ext: idle: Explicitly pass allowed cpumask to scx_select_cpu_dfl() Andrea Righi
2025-03-14 9:45 ` [PATCH 5/8] sched_ext: idle: Accept an arbitrary cpumask in scx_select_cpu_dfl() Andrea Righi
2025-03-14 9:45 ` [PATCH 6/8] sched_ext: idle: Introduce scx_bpf_select_cpu_and() Andrea Righi
2025-03-15 1:35 ` Changwoo Min
2025-03-15 9:08 ` Andrea Righi [this message]
2025-03-14 9:45 ` [PATCH 7/8] selftests/sched_ext: Add test for scx_bpf_select_cpu_and() Andrea Righi
2025-03-14 9:45 ` [PATCH 8/8] sched_ext: idle: Deprecate scx_bpf_select_cpu_dfl() 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=Z9VDjLzd8CA-Xf9N@gpd3 \
--to=arighi@nvidia.com \
--cc=bpf@vger.kernel.org \
--cc=changwoo@igalia.com \
--cc=linux-kernel@vger.kernel.org \
--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