Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20200703155749.GA6255@pc636> <8a2a55e6-6087-e4bf-3d35-ed4b4c216369@sony.com>
 <20200703192807.GB5207@pc636>
In-Reply-To: <20200703192807.GB5207@pc636>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri, 3 Jul 2020 13:08:55 -0700
Message-ID: <CAHk-=wiagrzJs9OBe_6bHK+Cc6RdoCOV85CiJAd3MhYnc8idfw@mail.gmail.com>
Subject: Re: nr_cpu_ids vs AMD 3970x(32 physical CPUs)
To:     Uladzislau Rezki <urezki@gmail.com>
Cc:     peter enderborg <peter.enderborg@sony.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Linux-MM <linux-mm@kvack.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        GregKroah-Hartmangregkh@linuxfoundation.org,
        Peter Zijlstra <peterz@infradead.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Fri, Jul 3, 2020 at 12:28 PM Uladzislau Rezki <urezki@gmail.com> wrote:
>
> I have MSI TRX40 with latest BIOS.

I think it's just that the BIOS is set for the max possible, in case
you'd have a 3990X.

I compile my kernel with CONFIG_NR_CPUS's set to 64. That works around
the issue.

Lots of distros seem to set CONFIG_MAXSMP to true, which I guess is
the most generic thing to do, but the problem with that is not just
the silly problem with the BIOS, but it also means that the kernel
does dynamic allocation for cpumasks even if you _don't_ have that
problem, because at compile-time you don't know how big the cpumask
will be.

With CONFIG_NR_CPUS's set to 64, the kernel will just use a "unsigned
long" on the stack (and in various data structures) and be done with
it, and not do unnecessary dynamic allocations.

                Linus