linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
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>
Subject: Re: nr_cpu_ids vs AMD 3970x(32 physical CPUs)
Date: Fri, 3 Jul 2020 13:08:55 -0700	[thread overview]
Message-ID: <CAHk-=wiagrzJs9OBe_6bHK+Cc6RdoCOV85CiJAd3MhYnc8idfw@mail.gmail.com> (raw)
In-Reply-To: <20200703192807.GB5207@pc636>

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

  reply	other threads:[~2020-07-03 20:09 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-03 15:57 nr_cpu_ids vs AMD 3970x(32 physical CPUs) Uladzislau Rezki
2020-07-03 16:56 ` Peter Zijlstra
2020-07-03 17:09   ` Uladzislau Rezki
2020-07-03 17:38     ` Peter Zijlstra
2020-07-03 19:26       ` Uladzislau Rezki
2020-07-03 17:07 ` Gabriel C
2020-07-03 17:24   ` Uladzislau Rezki
2020-07-03 17:45   ` Peter Zijlstra
2020-07-03 18:36     ` Gabriel C
2020-07-03 19:05 ` peter enderborg
2020-07-03 19:28   ` Uladzislau Rezki
2020-07-03 20:08     ` Linus Torvalds [this message]
2020-07-03 21:20       ` Uladzislau Rezki
2020-07-03 21:51         ` Matthew Wilcox
2020-07-03 22:22           ` Uladzislau Rezki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHk-=wiagrzJs9OBe_6bHK+Cc6RdoCOV85CiJAd3MhYnc8idfw@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=GregKroah-Hartmangregkh@linuxfoundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=peter.enderborg@sony.com \
    --cc=peterz@infradead.org \
    --cc=urezki@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).