All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.