Re: [PATCH v14 08/14] mm: multi-gen LRU: support page table walks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



As someone who still regularly uses hardware from this era, and often runs Linux on it, this would definitely be a blow to which machines I can actively use. Linux support is a big part of how I use these machines, since DOS and Windows 95 really can’t keep up with modern networking standards.

I would be very disappointed, and impacted, if Linux dropped 486 support.

On 10/20/22 23:10, Linus Torvalds wrote:
On Thu, Oct 20, 2022 at 11:55 AM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
On Thu, Oct 20, 2022 at 10:35:28AM -0700, Linus Torvalds wrote:
That said, I reacted to that cmpxchg loop:

         } while (cmpxchg64(&pmdp->pmd, old.pmd, 0ULL) != old.pmd);

is this series just so old (but rebased) that it doesn't use "try_cmpxchg64()"?
Yep -- it's *that* old :-/ You're not in fact the first to point that
out.

I'll make time tomorrow to fix it up and respin and send out. This is as
good a time as any to get rid of carrying these patches myself.
Hmm. Thinking some more about it, even if you do it as a
try_cmpxchg64() loop, it ends up being duplicated twice.

Maybe we should just bite the bullet, and say that we only support
x86-32 with 'cmpxchg8b' (ie Pentium and later).

Get rid of all the "emulate 64-bit atomics with cli/sti, knowing that
nobody has SMP on those CPU's anyway", and implement a generic x86-32
xchg() setup using that try_cmpxchg64 loop.

I think most (all?) distros already enable X86_PAE anyway, which makes
that X86_CMPXCHG64 be part of the base requirement.

Not that I'm convinced most distros even do 32-bit development anyway
these days.

(Of course, if we require X86_CMPXCHG64, we'll also hit some of the
odd clone CPU's that actually *do* support the instruction, but do not
report it in cpuid due to an odd old Windows NT bug. IOW, things like
the Cyrix and Transmeta CPU's did support the instruction, but had the
CX8 bit clear because otherwise NT wouldn't boot. We may or may not
get those cases right, but I doubt anybody really has any of those old
CPUs).

We got rid of i386 support back in 2012. Maybe it's time to get rid of
i486 support in 2022?

That way we could finally get rid of CONFIG_MATH_EMULATION too.

                Linus




[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux