[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <8734rhyl1g.ffs@tglx>
Date: Fri, 19 Apr 2024 07:32:43 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Alexey Dobriyan <adobriyan@...il.com>, peterz@...radead.org
Cc: adobriyan@...il.com, yury.norov@...il.com, linux@...musvillemoes.dk,
akpm@...ux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] cpu: memoise number of possible cpus
On Thu, Apr 18 2024 at 07:19, Alexey Dobriyan wrote:
memoise?
> cpu_possible_mask is fixed after boot, so it makes sense
> to calculate number of possible cpus to
The kernel calculates the number of possible CPUs already today, no?
> a) make num_possible_cpus() faster (distros ship with _large_ NR_CPUS),
> b) unscrew codegen elsewhere replacing function call
> with simple memory load.
Can we please have complete sentences which use precise technical
wording to describe the changes?
> diff --git a/init/main.c b/init/main.c
> index 881f6230ee59..fe0291b44d78 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -904,6 +904,9 @@ void start_kernel(void)
> setup_boot_config();
> setup_command_line(command_line);
> setup_nr_cpu_ids();
> +#if NR_CPUS > 1
> + num_possible_cpus = cpumask_weight(cpu_possible_mask);
> +#endif
setup_nr_cpu_ids() does exactly the same thing despite using a different
algorithm. So why not do the obvious and have:
#define num_possible_cpus() nr_cpu_ids
and make nr_cpu_ids __ro_after_init?
Which made me look at CONFIG_FORCE_NR_CPUS. That's simply broken
because:
static inline void set_nr_cpu_ids(unsigned int nr)
{
#if (NR_CPUS == 1) || defined(CONFIG_FORCE_NR_CPUS)
WARN_ON(nr != nr_cpu_ids);
#else
nr_cpu_ids = nr;
#endif
}
So if num_possible_cpus() != nr_cpu_ids then everything after that
becomes lottery. If that hard-coded NR_CPUS is actually worth it then
this WARN_ON() is just wrong. The only sensible solution to that is to
make it a BUG_ON().
Thanks,
tglx
Powered by blists - more mailing lists