linux-kernel - Re: [PATCH] sched: change MAX_SHARES to NR

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: <CA+WzAR=gnECdMh2vdJYHi9vK0GGw27xDNfgpL+ZE_jTLSu=0Xw@mail.gmail.com>
Date: Tue, 12 Aug 2025 20:04:41 +0800
From: Zhenguo Yao <yaozhenguo1@...il.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: mingo@...hat.com, vincent.guittot@...aro.org, linux-kernel@...r.kernel.org, 
	yaozhenguo@...com
Subject: Re: [PATCH] sched: change MAX_SHARES to NR_CPUS

Peter Zijlstra <peterz@...radead.org> 于2025年8月12日周二 18:00写道：
>
> On Tue, Aug 12, 2025 at 05:28:10PM +0800, yaozhenguo wrote:
> > From: ZhenguoYao <yaozhenguo1@...il.com>
> >
> > As the number of cores in modern CPUs continues to increase,
> > 256 * 1024 is no longer sufficient to meet the requirements.
> > Therefore, MAX_SHARES is being modified to NR_CPUS * 1024.
>
> You forgot to explain why this needs to scale with CPUs, you also forgot
> to provide an argument for why this will not introduce numerical issues.
>
emm！It’s such a scenario，our server with 384 CPUs  as a cloud
computing host running multiple VMs. We need to configure different
CPU shares for VMs of varying specifications. For example: An 8-vCPU
VM is allocated 8*1024 shares. The
/sys/fs/cgroup/cpu/machine.slice/cpu.shares is set to (total cores -
reserved cores)*1024 (e.g., 380*1024 when reserving 4 cores). Purpose
is to minimize interference from system processes on VMs and to ensure
differentiated CPU capacity for different VM specs under high load.
Assumption: 1024 shares represent 1 CPU’s computing power (please
correct me if it is wrong).

The MAX_SHARES threshold (set to 1<<18UL) prevents this configuration
as it reaches the maximum allowed value.

Regarding numerical issues - are you referring to potential unsigned
long overflow when NR_CPUS is too large? I couldn’t find historical
commit records explaining why MAX_SHARES was set to 1<<18UL.

Alternatively, my understanding of this "share" could be completely
wrong. If that's the case, please correct me. Thank you very much!

> > Signed-off-by: ZhenguoYao <yaozhenguo1@...il.com>
> > ---
> >  kernel/sched/sched.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> > index be9745d104f7..5c219e34f48d 100644
> > --- a/kernel/sched/sched.h
> > +++ b/kernel/sched/sched.h
> > @@ -510,7 +510,7 @@ struct task_group {
> >   *  limitation from this.)
> >   */
> >  #define MIN_SHARES           (1UL <<  1)
> > -#define MAX_SHARES           (1UL << 18)
> > +#define MAX_SHARES           (NR_CPUS * 1024UL)
> >  #endif
> >
> >  typedef int (*tg_visitor)(struct task_group *, void *);
> > --
> > 2.43.5
> >