From: Yury Norov <yury.norov@gmail.com>
To: Andrea Righi <arighi@nvidia.com>
Cc: Tejun Heo <tj@kernel.org>, David Vernet <void@manifault.com>,
Changwoo Min <changwoo@igalia.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] sched_ext: idle: Skip cross-node search with !CONFIG_NUMA
Date: Wed, 4 Jun 2025 10:05:15 -0400 [thread overview]
Message-ID: <aEBSm7Lm9Gx_anMo@yury> (raw)
In-Reply-To: <20250603082201.173642-1-arighi@nvidia.com>
Hi Andrea!
On Tue, Jun 03, 2025 at 10:22:01AM +0200, Andrea Righi wrote:
> In the idle CPU selection logic, attempting cross-node searches adds
> unnecessary complexity when CONFIG_NUMA is disabled.
>
> Since there's no meaningful concept of nodes in this case, simplify the
> logic by restricting the idle CPU search to the current node only.
>
> Fixes: 48849271e6611 ("sched_ext: idle: Per-node idle cpumasks")
> Signed-off-by: Andrea Righi <arighi@nvidia.com>
> ---
> kernel/sched/ext_idle.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/kernel/sched/ext_idle.c b/kernel/sched/ext_idle.c
> index 66da03cc0b338..8660d9ae40169 100644
> --- a/kernel/sched/ext_idle.c
> +++ b/kernel/sched/ext_idle.c
> @@ -138,6 +138,7 @@ static s32 pick_idle_cpu_in_node(const struct cpumask *cpus_allowed, int node, u
> goto retry;
> }
>
> +#ifdef CONFIG_NUMA
It would be more natural if you move this inside the function body,
and not duplicate the function declaration.
> /*
> * Tracks nodes that have not yet been visited when searching for an idle
> * CPU across all available nodes.
> @@ -186,6 +187,13 @@ static s32 pick_idle_cpu_from_online_nodes(const struct cpumask *cpus_allowed, i
>
> return cpu;
> }
> +#else
> +static inline s32
> +pick_idle_cpu_from_online_nodes(const struct cpumask *cpus_allowed, int node, u64 flags)
> +{
> + return -EBUSY;
> +}
This is misleading errno. The system is nut busy, it is disabled. If
it was a syscall, I would say you should return ENOSYS. ENODATA is
another candidate. Or you have a special policy for the subsystem/
The above pick_idle_cpu_in_node() doesn't have CONFIG_NUMA protection
as well. Is it safe against CONFIG_NUMA?
> +#endif
>
> /*
> * Find an idle CPU in the system, starting from @node.
> --
> 2.49.0
next prev parent reply other threads:[~2025-06-04 14:05 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-03 8:22 [PATCH] sched_ext: idle: Skip cross-node search with !CONFIG_NUMA Andrea Righi
2025-06-03 18:29 ` Tejun Heo
2025-06-04 14:05 ` Yury Norov [this message]
2025-06-04 15:07 ` 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=aEBSm7Lm9Gx_anMo@yury \
--to=yury.norov@gmail.com \
--cc=arighi@nvidia.com \
--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 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.