Re: [PATCH] [RFC] x86/cpu: rework instruction set selection

["Arnd Bergmann" <arnd@xxxxxxxx>]

On Sat, Apr 26, 2025, at 21:09, Ingo Molnar wrote:
> * Arnd Bergmann <arnd@xxxxxxxx> wrote:
>
>> CMOV is missing not just on old Socket 5/7 CPUs (Pentium MMX, AMD K6, 
>> Cyrix MII) but also newer embedded Via C3, Geode GX and 
>> Vortex86DX/MX/EX/DX2. The replacement Nehemiah (2003), GeodeLX (2005) 
>> and Vortex86DX3/EX2 (2015!) have CMOV, but the old ones were sold 
>> alongside them for years, and some of the 586-class Vortex86 products 
>> are still commercially available.
>
> Very few (if any) of the commercially available products will run 
> modern 6.16+ kernels, right?

No, at least not in absolute numbers. As far as I can tell, the RDC
SoC family is the only one that is still around, after Quark, Geode
and Eden were all discontinued around 2019.

There are multiple known RDC licensees (DM&P/Vortex86, xlichip) and
probably a few more with custom chips. They lag behind Intel and AMD
by about one patent expiration time, and maybe a decade behind Arm
SoCs, so they only just arrived at quad-core SMP, LPDDR4, and SSSE3
instructions and have announced upcoming 64-bit chips.

They do have super-long support cycles, and there are a few markets
that absolutely require kernel updates for many years, so I would
still consider the 586-class embedded chips more relevant for future
kernels than 30 year old PCs, and the 686-class embedded chips
more relevant than 20 year old laptops.

> Note that the real danger the 32-bit x86 kernel is going to be facing 
> in 2-5 years is total removal due to lack of development interest, but 
> I think we can support 686+ reasonably far into the future, and can 
> keep it tested reasonably - while covering like 99%+ of the currently 
> available 32-bit-only x86 products on the market. The fewer variants, 
> the better.

I agree that this is the endgame for x86-32 and that eventually
the while thing will be remove, and every simplification helps, but
I still don't think that removing 586 earlier helps enough to
outweigh the cost here.

The situation is similar on 32-bit Arm, where we currently support
armv4, armv4t, armv5, armv6, armv6k, armv7, armv7ve and armv8-aarch32.
Removing armv3 a few years ago helped a lot, removing the extremely
rare armv6 will help as well, but there is little value in dropping
CPU support for v4 and v4t as long as v5 is there, or v6k and v7
as long as we have v7ve and v8-aarch32. My guess would be that we
can remove armv4/v4t/v5 at the same time as i586/i686 and
some other 32-bit targets, followed by armv7/v7ve/v8-aarch32
much later.

       Arnd