From: Ingo Molnar <mingo@kernel.org>
To: Borislav Petkov <bp@alien8.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
x86-ml <x86@kernel.org>, lkml <linux-kernel@vger.kernel.org>,
linux-edac <linux-edac@vger.kernel.org>
Subject: Re: [GIT PULL] EDAC updates for v6.9
Date: Tue, 12 Mar 2024 10:16:10 +0100 [thread overview]
Message-ID: <ZfAdWtBt60hAx//4@gmail.com> (raw)
In-Reply-To: <20240312074504.GAZfAIANxTdC5Tb0vb@fat_crate.local>
* Borislav Petkov <bp@alien8.de> wrote:
> On Mon, Mar 11, 2024 at 06:12:54PM -0700, Linus Torvalds wrote:
> > Ho humm. Lookie here:
> >
> > static inline unsigned int topology_amd_nodes_per_pkg(void)
> > { return 0; };
> >
> > that's the UP case.
> >
> > Yeah, I'm assuming nobody tests this for UP,
>
> Unless it gets randomly enabled in my randconfig builds once in a blue
> moon, I'd say pretty seldomly. I've heard people raise the question
> multiple times whether we should simply make CONFIG_SMP default y on x86
> and frankly, it'll get rid of a whole bunch of stupid corner cases like
> that...
Making it 'default y' in the Kconfig alone changes very little, as people &
bots will still stumble on !SMP via allnoconfig or randconfig builds.
If you mean forcing CONFIG_SMP via 'select SMP' on x86 on the other hand,
that's worth considering - although I think there will be a ton of extra
cross-build breakage as most patches still get created & tested on x86.
In other words, the x86 UP build basically has the side-effect utility of
covering a lot of UP cross-build scenarios in generic code.
I think the most viable approach would be to make SMP the only model all
across the kernel (and eventually removing the CONFIG_SMP option), while
propagating UP data structures and locking primitives to the UP arch level,
instead of having CONFIG_SMP #ifdefs in generic code.
Maybe not today, but certainly in a few years.
Thanks,
Ingo
next prev parent reply other threads:[~2024-03-12 9:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-11 15:57 [GIT PULL] EDAC updates for v6.9 Borislav Petkov
2024-03-12 1:12 ` Linus Torvalds
2024-03-12 2:24 ` Randy Dunlap
2024-03-12 2:25 ` Linus Torvalds
2024-03-12 7:45 ` Borislav Petkov
2024-03-12 9:16 ` Ingo Molnar [this message]
2024-03-12 9:29 ` Borislav Petkov
2024-03-12 10:07 ` Thomas Gleixner
2024-03-12 1:30 ` pr-tracker-bot
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=ZfAdWtBt60hAx//4@gmail.com \
--to=mingo@kernel.org \
--cc=bp@alien8.de \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.