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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7A342FA373D for ; Thu, 27 Oct 2022 23:08:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CDF706B0072; Thu, 27 Oct 2022 19:08:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C67DF6B0073; Thu, 27 Oct 2022 19:08:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B08388E0001; Thu, 27 Oct 2022 19:08:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 9DE5E6B0072 for ; Thu, 27 Oct 2022 19:08:22 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 71322120182 for ; Thu, 27 Oct 2022 23:08:22 +0000 (UTC) X-FDA: 80068270044.14.24D2549 Received: from angie.orcam.me.uk (angie.orcam.me.uk [78.133.224.34]) by imf19.hostedemail.com (Postfix) with ESMTP id 369451A0010 for ; Thu, 27 Oct 2022 23:08:20 +0000 (UTC) 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 ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1666912101; a=rsa-sha256; cv=none; b=kZKmvpibr3BBIa4btwtdxSE6XMyNx9I+9r3V62ZF3OykCr7iDA5mSW2kMtJbxS+3RLrqrL 7TmgdRVjRgdYoYTrcbKwROfXXVccmvSyY/hs+Y7a5QvU1OMcoENDWOZRaYa1F7ejkrqbPY +0K0ejdS/FMYNzqoIrcnE4GKMkDfFv0= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=none; spf=none (imf19.hostedemail.com: domain of macro@orcam.me.uk has no SPF policy when checking 78.133.224.34) smtp.mailfrom=macro@orcam.me.uk; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1666912101; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QW595s069vmzerKSgLDJweU2kD2Ntg9gL95MF+otQAw=; b=6DqwUs1U4sOxtd5HCy8cay6onLbZgyMTiSGKIPzO0zc8STYt3XMxp2qsRP0hClI1o98seG XnoNVyp7rwHpWRUZiHA6JrQ/wjx6XqMhxd2pE+q3Iz9ZXbMvplnSf++jRSVwu/WSq1WaTh Hulc3rZAFv92PeImhhEeOLNYO+yzANc= Authentication-Results: imf19.hostedemail.com; dkim=none; spf=none (imf19.hostedemail.com: domain of macro@orcam.me.uk has no SPF policy when checking 78.133.224.34) smtp.mailfrom=macro@orcam.me.uk; dmarc=none X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 369451A0010 X-Stat-Signature: td93tick3njqgzerc4ixk7ghga3bj1gt X-Rspam-User: X-HE-Tag: 1666912100-429030 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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