Re: [PATCH v2 0/5] cpumask: cleanup nr_cpu_ids vs nr_cpumask_bits mess

[Yury Norov <yury.norov@gmail.com>]

On Tue, Sep 6, 2022 at 8:45 AM Valentin Schneider <vschneid@redhat.com> wrote:
>
> On 06/09/22 16:38, Peter Zijlstra wrote:
> > On Tue, Sep 06, 2022 at 01:06:47PM +0100, Valentin Schneider wrote:
> >
> >>   #define nr_cpumask_bits nr_cpu_ids
> >
> > That assumes the CPU space is dense; is this so? That is, you can have 4
> > CPUs while the highest cpu number is vastly larger than 4.

It's quite common. One can configure qemu to give to the user one cpu at
start, and hotplug more on demand. In that case those unattached CPUS
are set in cpu_possible_mask.

> > It's uncommon, but not unheard of I think. ISTR some BIOSes leaving
> > holes in the CPU space when there were empty CPU sockets on the
> > motherboard.

Didn't get my hands on that particular board, but I suspect that those missed
CPUs will be set in possible mask, and unset in present, online and active
masks.

> I'd assume this would be visible in the cpu_possible_mask and thus be
> properly reflected in nr_cpu_ids. Otherwise that would already break with
> CONFIG_CPUMASK_OFFSTACK=y, I think.

Yes.

The nr_cpu_ids is set as:
  find_last_bit(cpumask_bits(cpu_possible_mask), NR_CPUS) + 1

For all board and VM configurations I've been working with, the
cpu_possible_mask
was dense up to nr_cpu_ids.The holes that may appear if HOTPLUG is enabled
or by any other reason are all in the present mask, and therefore
nr_cpu_ids is set
correctly.