From: Ingo Molnar <mingo@kernel.org>
To: Arnd Bergmann <arnd@kernel.org>
Cc: "Thomas Gleixner" <tglx@linutronix.de>,
"Ingo Molnar" <mingo@redhat.com>,
"Borislav Petkov" <bp@alien8.de>,
"Dave Hansen" <dave.hansen@linux.intel.com>,
x86@kernel.org, "Arnd Bergmann" <arnd@arndb.de>,
"H. Peter Anvin" <hpa@zytor.com>,
"Juergen Gross" <jgross@suse.com>,
"Boris Ostrovsky" <boris.ostrovsky@oracle.com>,
"Alexander Usyskin" <alexander.usyskin@intel.com>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Mateusz Jończyk" <mat.jonczyk@o2.pl>,
"Mike Rapoport (Microsoft)" <rppt@kernel.org>,
"Ard Biesheuvel" <ardb@kernel.org>,
"Peter Zijlstra" <peterz@infradead.org>,
linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
"Linus Torvalds" <torvalds@linux-foundation.org>
Subject: Re: [PATCH] [RFC] x86/cpu: rework instruction set selection
Date: Sat, 26 Apr 2025 11:08:17 +0200 [thread overview]
Message-ID: <aAyiganPp_UsNlnZ@gmail.com> (raw)
In-Reply-To: <20250425141740.734030-1-arnd@kernel.org>
* Arnd Bergmann <arnd@kernel.org> wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> With cx8 and tsc being mandatory features, the only important
> architectural features are now cmov and pae.
>
> Change the large list of target CPUs to no longer pick the instruction set
> itself but only the mtune= optimization level and in-kernel optimizations
> that remain compatible with all cores.
>
> The CONFIG_X86_CMOV instead becomes user-selectable and is now how
> Kconfig picks between 586-class (Pentium, Pentium MMX, K6, C3, GeodeGX)
> and 686-class (everything else) targets.
>
> In order to allow running on late 32-bit cores (Athlon, Pentium-M,
> Pentium 4, ...), the X86_L1_CACHE_SHIFT can no longer be set to anything
> lower than 6 (i.e. 64 byte cache lines).
>
> The optimization options now depend on X86_CMOV and X86_PAE instead
> of the other way round, while other compile-time conditionals that
> checked for MATOM/MGEODEGX1 instead now check for CPU_SUP_* options
> that enable support for a particular CPU family.
>
> Link: https://lore.kernel.org/lkml/dd29df0c-0b4f-44e6-b71b-2a358ea76fb4@app.fastmail.com/
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> This is what I had in mind as mentioned in the earlier thread on
> cx8/tsc removal. I based this on top of the Ingo's [RFC 15/15]
> patch.
> ---
> arch/x86/Kconfig | 2 +-
> arch/x86/Kconfig.cpu | 100 ++++++++++++++------------------
> arch/x86/Makefile_32.cpu | 48 +++++++--------
> arch/x86/include/asm/vermagic.h | 36 +-----------
> arch/x86/kernel/tsc.c | 2 +-
> arch/x86/xen/Kconfig | 1 -
> drivers/misc/mei/Kconfig | 2 +-
> 7 files changed, 74 insertions(+), 117 deletions(-)
While the simplification is nice on its face, this looks messy:
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index a9d717558972..1e33f88c9b97 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -1438,7 +1438,7 @@ config HIGHMEM
>
> config X86_PAE
> bool "PAE (Physical Address Extension) Support"
> - depends on X86_32 && X86_HAVE_PAE
> + depends on X86_32 && X86_CMOV
Coupling CMOV to PAE ... :-/
> +config X86_CMOV
> + bool "Require 686-class CMOV instructions" if X86_32
> + default y
> help
> - This is the processor type of your CPU. This information is
> - used for optimizing purposes. In order to compile a kernel
> - that can run on all supported x86 CPU types (albeit not
> - optimally fast), you can specify "586" here.
> + Most x86-32 processor implementations are compatible with
> + the the CMOV instruction originally added in the Pentium Pro,
> + and they perform much better when using it.
> +
> + Disable this option to build for 586-class CPUs without this
> + instruction. This is only required for the original Intel
> + Pentium (P5, P54, P55), AMD K6/K6-II/K6-3D, Geode GX1 and Via
> + CyrixIII/C3 CPUs.
Very few users will know anything about CMOV.
I'd argue the right path forward is to just bite the bullet and remove
non-CMOV support as well, that would be the outcome *anyway* in a few
years. That would allow basically a single 'modern' 32-bit kernel that
is supposed to boot on every supported CPU. People might even end up
testing it ... ;-)
Thanks,
Ingo
next prev parent reply other threads:[~2025-04-26 9:09 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-25 14:15 [PATCH] [RFC] x86/cpu: rework instruction set selection Arnd Bergmann
2025-04-25 15:34 ` H. Peter Anvin
2025-04-25 16:13 ` Arnd Bergmann
2025-04-25 20:15 ` H. Peter Anvin
2025-04-26 9:08 ` Ingo Molnar [this message]
2025-04-26 13:17 ` H. Peter Anvin
2025-04-26 18:55 ` Ingo Molnar
2025-04-27 0:35 ` H. Peter Anvin
2025-04-26 18:58 ` Arnd Bergmann
2025-04-26 19:09 ` Ingo Molnar
2025-04-27 13:24 ` Arnd Bergmann
2025-04-27 21:17 ` H. Peter Anvin
2025-04-26 19:24 ` Linus Torvalds
2025-04-26 19:55 ` Linus Torvalds
2025-04-26 23:47 ` H. Peter Anvin
2025-04-27 10:18 ` Ingo Molnar
2025-04-27 0:02 ` H. Peter Anvin
2025-04-27 19:17 ` Andrew Cooper
2025-04-27 19:34 ` Linus Torvalds
2025-04-27 21:14 ` H. Peter Anvin
2025-04-28 6:58 ` [PATCH] bitops/32: Convert variable_ffs() and fls() zero-case handling to C Ingo Molnar
2025-04-28 7:05 ` Ingo Molnar
2025-04-28 7:14 ` Ingo Molnar
2025-04-28 12:30 ` Arnd Bergmann
2025-04-28 13:41 ` H. Peter Anvin
2025-04-28 16:23 ` Linus Torvalds
2025-04-29 10:08 ` Ingo Molnar
2025-04-29 14:32 ` H. Peter Anvin
2025-04-28 16:14 ` Linus Torvalds
2025-04-28 21:38 ` H. Peter Anvin
2025-04-29 0:12 ` Andrew Cooper
2025-04-29 2:00 ` H. Peter Anvin
2025-04-29 2:22 ` Linus Torvalds
2025-04-29 2:25 ` Andrew Cooper
2025-04-29 3:13 ` H. Peter Anvin
2025-04-29 14:38 ` Andrew Cooper
2025-04-29 18:05 ` Linus Torvalds
2025-04-29 19:13 ` Andrew Cooper
2025-04-29 20:12 ` Linus Torvalds
2025-04-29 21:23 ` H. Peter Anvin
2025-04-29 21:53 ` Linus Torvalds
2025-04-29 21:59 ` Andrew Cooper
2025-04-29 22:04 ` Linus Torvalds
2025-04-29 22:10 ` H. Peter Anvin
2025-04-29 22:22 ` Andrew Cooper
2025-04-29 22:34 ` Linus Torvalds
2025-04-27 9:50 ` [PATCH] [RFC] x86/cpu: rework instruction set selection Ingo Molnar
2025-04-30 21:54 ` David Laight
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=aAyiganPp_UsNlnZ@gmail.com \
--to=mingo@kernel.org \
--cc=alexander.usyskin@intel.com \
--cc=ardb@kernel.org \
--cc=arnd@arndb.de \
--cc=arnd@kernel.org \
--cc=boris.ostrovsky@oracle.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=hpa@zytor.com \
--cc=jgross@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mat.jonczyk@o2.pl \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rppt@kernel.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.org \
--cc=xen-devel@lists.xenproject.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.