From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 04BDAFA373D for ; Thu, 27 Oct 2022 23:08:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235270AbiJ0XIz (ORCPT ); Thu, 27 Oct 2022 19:08:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58180 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234803AbiJ0XIw (ORCPT ); Thu, 27 Oct 2022 19:08:52 -0400 Received: from angie.orcam.me.uk (angie.orcam.me.uk [78.133.224.34]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 62CA78FD4A for ; Thu, 27 Oct 2022 16:08:51 -0700 (PDT) Received: by angie.orcam.me.uk (Postfix, from userid 500) id 4729E92009D; Fri, 28 Oct 2022 01:08:18 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id 3E4F792009B; Fri, 28 Oct 2022 00:08:18 +0100 (BST) Date: Fri, 28 Oct 2022 00:08:18 +0100 (BST) From: "Maciej W. Rozycki" To: Arnd Bergmann cc: Linus Torvalds , Matthew Wilcox , Peter Zijlstra , the arch/x86 maintainers , Yu Zhao , Andrew Morton , Andi Kleen , Aneesh Kumar , Catalin Marinas , Dave Hansen , Hillf Danton , Jens Axboe , Johannes Weiner , Jonathan Corbet , Mel Gorman , Michael Larabel , Michal Hocko , Mike Rapoport , Tejun Heo , Vlastimil Babka , Will Deacon , linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, page-reclaim@google.com, Brian Geffon , Jan Alexander Steffens , Oleksandr Natalenko , Steven Barrett , Suleiman Souhlal , Daniel Byrne , Donald Carr , =?UTF-8?Q?Holger_Hoffst=C3=A4tte?= , Konstantin Kharlamov , Shuang Zhai , Sofia Trinh , Vaibhav Jain Subject: Re: [PATCH v14 08/14] mm: multi-gen LRU: support page table walks In-Reply-To: Message-ID: References: <20220815071332.627393-1-yuzhao@google.com> <20220815071332.627393-9-yuzhao@google.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 26 Oct 2022, Arnd Bergmann wrote: > >> In fact, I don't understand how current kernels work on an i486 at > >> all, since it looks like > >> > >> exit_to_user_mode_prepare -> > >> arch_exit_to_user_mode_prepare > >> > >> ends up having an unconditional 'rdtsc' instruction in it. > >> > > > The fix here is obviously and trivially: > > > > select HAVE_ARCH_RANDOMIZE_KSTACK_OFFSET if !M486SX && !M486 > > I think that would be "if X86_TSC", otherwise you still include the > TSC-less 586-class (5x86, 6x86, Elan, Winchip C6, MediaGX, ...) Right, I tend to forget about these more exotic chips from the 1990s era. I'll run some verification and come up with the actual fix in the next several days. > > So what's the actual burden from keeping this support around? Would my > > proposal to emulate CMPXCHG8B (and possibly RDTSC) in #UD handler help? > > That sounds worse to me than the current use of runtime alternatives > for picking between cmpxchg8b_emu and the native instruction. Why is that so? Because of the trap-and-emulate technique? It's been around since forever and specified in some processor ISAs even, where some machine instructions are explicitly allowed to be omitted from actual hardware and delegated to OS emulation without making affected hardware non-compliant. VAX had it back from 1970s and RISC-V has it now. We've been using it to retrofit operations ourselves, though maybe not with the x86 arch. Or is it because of the complex address decoding x86 requires? Well, I have actually realised we do have it already, in the x87 CR0.EM emulator. While IEEE-754 exceptions can make use of the address of the operand recorded in the FPU environment full emulation requires decoding by hand. > For arm32, we have a combination of two other approaches: > > - On the oldest processors that never had SMP support (ARMv5 and > earlier), it is not possible to enable support for SMP at all. > Using a Kconfig 'depends on X86_CMPXCHG64' for CONFIG_SMP would > still allow building 486 kernels, but completely avoid the problem > of trying to make the same kernel work on later SMP machines. That would be fine with me of course. > - For the special case of early ARMv6 hardware that has 32-bit > atomics but not 64-bit ones, the kernel just falls back to > CONFIG_GENERIC_ATOMIC64 and no cmpxchg64(). The same should work > for an i486+SMP kernel. It's obviously slower, but most users > can trivially avoid this by either running an i686 SMP kernel > or an i486 UP kernel. You meant an M586TSC+ SMP kernel presumably (I have such a machine), but otherwise I'd be fine with such an approach too. So it looks to me like we have at least three options to keep 486 alive, two of which seem fairly straightforward to deploy and maintain long-term. I like your last proposal the most, FWIW. Do we have a consensus here? Maciej