Re: [PATCH] cpu: memoise number of possible cpus

[Thomas Gleixner]

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