linux-kernel - Re: [PATCH 2/3] sched_ext: Introduce per-NUMA idle cpumasks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Z1ClG6qOvesfyGSU@slm.duckdns.org>
Date: Wed, 4 Dec 2024 08:53:15 -1000
From: Tejun Heo <tj@...nel.org>
To: Andrea Righi <arighi@...dia.com>
Cc: David Vernet <void@...ifault.com>, Yury Norov <yury.norov@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] sched_ext: Introduce per-NUMA idle cpumasks

Hello,

On Wed, Dec 04, 2024 at 09:41:43AM +0100, Andrea Righi wrote:
...
> I like the idea of introducing a flag. The default should be flattened
> cpumask, so everything remains the same, and if a scheduler explicitly
> enables SCX_OPS_NUMA_IDLE_MASK (suggestions for the name?) we can switch
> to the NUMA-aware idle logic.

I think it generally works better to use "node" instead of "numa" for these
interfaces. That's more common and matches the interface functions that need
to be used and exposed, so maybe sth like SCX_OPS_BUILTIN_IDLE_PER_NODE or
SCX_OPS_NODE_BUILTIN_IDLE?

Thanks.

-- 
tejun