[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250812100035.GG4067720@noisy.programming.kicks-ass.net>
Date: Tue, 12 Aug 2025 12:00:35 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: yaozhenguo <yaozhenguo1@...il.com>
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
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.
> 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
>
Powered by blists - more mailing lists