From: ZhenguoYao <yaozhenguo1@gmail.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.

Signed-off-by: ZhenguoYao <yaozhenguo1@gmail.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

On Tue, Aug 12, 2025 at 05:28:10PM +0800, yaozhenguo wrote:
> From: ZhenguoYao <yaozhenguo1@gmail.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.

> Signed-off-by: ZhenguoYao <yaozhenguo1@gmail.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
>

Peter Zijlstra <peterz@infradead.org> 于2025年8月12日周二 18:00写道：
>
> On Tue, Aug 12, 2025 at 05:28:10PM +0800, yaozhenguo wrote:
> > From: ZhenguoYao <yaozhenguo1@gmail.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@gmail.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
> >