Received-SPF: pass (google.com: domain of linux-kernel+bounces-151013-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
From: Thomas Gleixner <tglx@linutronix.de>
To: Alexey Dobriyan <adobriyan@gmail.com>, peterz@infradead.org
Cc: adobriyan@gmail.com, yury.norov@gmail.com, linux@rasmusvillemoes.dk,
 akpm@linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] cpu: memoise number of possible cpus
In-Reply-To: <20240418041927.3903-1-adobriyan@gmail.com>
Date: Fri, 19 Apr 2024 07:32:43 +0200
Message-ID: <8734rhyl1g.ffs@tglx>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain

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