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 B0F3EECAAA1 for ; Sun, 23 Oct 2022 17:55:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id ECC64900003; Sun, 23 Oct 2022 13:55:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E5655900002; Sun, 23 Oct 2022 13:55:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CF5AD900003; Sun, 23 Oct 2022 13:55:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id BBB73900002 for ; Sun, 23 Oct 2022 13:55:11 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 9239B4088D for ; Sun, 23 Oct 2022 17:55:11 +0000 (UTC) X-FDA: 80052965622.20.B647C37 Received: from angie.orcam.me.uk (angie.orcam.me.uk [78.133.224.34]) by imf13.hostedemail.com (Postfix) with ESMTP id 3A5AA20014 for ; Sun, 23 Oct 2022 17:55:08 +0000 (UTC) Received: by angie.orcam.me.uk (Postfix, from userid 500) id 1094C92009C; Sun, 23 Oct 2022 19:55:04 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id 0010B92009B; Sun, 23 Oct 2022 18:55:04 +0100 (BST) Date: Sun, 23 Oct 2022 18:55:04 +0100 (BST) From: "Maciej W. Rozycki" To: Linus Torvalds cc: 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-Authentication-Results: i=1; imf13.hostedemail.com; dkim=none; spf=none (imf13.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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1666547710; a=rsa-sha256; cv=none; b=PPtYeNWjZTxantuQyGgvFMZt3nwG+JZXm9K43h+eSLA4i2HadmDXFYWKqfyyQm0H41CFqi V/3PeSDFFFqDXih4E2Cu/gQlkaxTaBU6cOgawiY069Zos+qvbzra6OldD9qpLA/VBArinL x90LeJR/A3rdPXLcNRgiTeWLUbA0DxE= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1666547710; 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=Ex1zhjzrB0OB/NO3b/61VnHl/R2ufOKTTjEixAxbgJI=; b=GshJqXTHkLqTdqeCs1602dYHHLW4VKueJWuSbO/1fEhnBge7QvzN3WonTShOxyMttY7m7+ 5WeKbyyeLDdRGA5PWiJmb2Gy94S0ChpArvvUaguTt/5dLK09mWemUa/3vijqgxk6rImhGO HwKc+6xpY8g5ikGc6S4m+Q36dYq2Ews= Authentication-Results: imf13.hostedemail.com; dkim=none; spf=none (imf13.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-Rspam-User: X-Rspamd-Server: rspam10 X-Stat-Signature: i7kkccj43rwrgepwjwz84o4jf6kqe5hf X-Rspamd-Queue-Id: 3A5AA20014 X-HE-Tag: 1666547708-952289 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 Fri, 21 Oct 2022, Linus Torvalds wrote: > > > We got rid of i386 support back in 2012. Maybe it's time to get rid of > > > i486 support in 2022? > > > > Arnd suggested removing i486 last year and got a bit of pushback. > > The most convincing to my mind was Maciej: > > Hmm. Maciej added to the cc. Thanks! > So I *really* don't think i486 class hardware is relevant any more. > Yes, I'm sure it exists (Maciej being an example), but from a kernel > development standpoint I don't think they are really relevant. > > At some point, people have them as museum pieces. They might as well > run museum kernels. > > Moving up to requiring cmpxchg8b doesn't sound unreasonable to me. But is it really a problem? I mean unlike MIPS R2000/R3000 class gear that has no atomics at all at the CPU level (SMP R3000 machines did exist and necessarily had atomics, actually via gating storage implemented by board hardware in systems we have never had support for even for UP) we have had atomics in x86 since forever. Just not 64-bit ones. Given the presence of generic atomics we can emulate CMPXCHG8B easily LL/SC-style using a spinlock with XCHG even on SMP let alone UP. So all the kernel code can just assume the presence of CMPXCHG8B, but any invocations of CMPXCHG8B would be diverted to the emulation, perhaps even at the assembly level via a GAS macro called `cmpxchg8b' (why not?). All the maintenance burden is then shifted to that macro and said emulation code. Proof of concept wrapper: #define LOCK_PREFIX "" #define CC_SET(c) "\n\t/* output condition code " #c "*/\n" #define CC_OUT(c) "=@cc" #c #define unlikely(x) __builtin_expect(!!(x), 0) __extension__ typedef unsigned long long __u64; typedef unsigned int __u32; typedef __u64 u64; typedef __u32 u32; typedef _Bool bool; __asm__( ".macro cmpxchg8b arg\n\t" "pushl %eax\n\t" "leal \\arg, %eax\n\t" "xchgl %eax, (%esp)\n\t" "call cmpxchg8b_emu\n\t" ".endm\n\t"); bool __try_cmpxchg64(volatile u64 *ptr, u64 *pold, u64 new) { bool success; u64 old = *pold; asm volatile(LOCK_PREFIX "cmpxchg8b %[ptr]" CC_SET(z) : CC_OUT(z) (success), [ptr] "+m" (*ptr), "+A" (old) : "b" ((u32)new), "c" ((u32)(new >> 32)) : "memory"); if (unlikely(!success)) *pold = old; return success; } This assembles to: cmpxchg8b.o: file format elf32-i386 Disassembly of section .text: 00000000 <__try_cmpxchg64>: 0: 55 push %ebp 1: 89 e5 mov %esp,%ebp 3: 57 push %edi 4: 56 push %esi 5: 89 d7 mov %edx,%edi 7: 53 push %ebx 8: 89 c6 mov %eax,%esi a: 8b 4d 0c mov 0xc(%ebp),%ecx d: 8b 02 mov (%edx),%eax f: 8b 5d 08 mov 0x8(%ebp),%ebx 12: 8b 52 04 mov 0x4(%edx),%edx 15: 50 push %eax 16: 8d 06 lea (%esi),%eax 18: 87 04 24 xchg %eax,(%esp) 1b: e8 fc ff ff ff call 1c <__try_cmpxchg64+0x1c> 1c: R_386_PC32 cmpxchg8b_emu 20: 0f 94 c1 sete %cl 23: 75 0b jne 30 <__try_cmpxchg64+0x30> 25: 5b pop %ebx 26: 88 c8 mov %cl,%al 28: 5e pop %esi 29: 5f pop %edi 2a: 5d pop %ebp 2b: c3 ret 2c: 8d 74 26 00 lea 0x0(%esi,%eiz,1),%esi 30: 5b pop %ebx 31: 89 07 mov %eax,(%edi) 33: 5e pop %esi 34: 89 57 04 mov %edx,0x4(%edi) 37: 5f pop %edi 38: 88 c8 mov %cl,%al 3a: 5d pop %ebp 3b: c3 ret Of course there's a minor ABI nit for `cmpxchg8b_emu' to return a result in ZF and the wrapper relies on CONFIG_FRAME_POINTER for correct `arg' evaluation in all cases. But that shouldn't be a big deal, should it? Then long-term maintenance would be minimal to nil and all the code except for the wrapper and the emulation handler need not be concerned about the 486 obscurity. I can volunteer to maintain said wrapper and emulation (and for that matter generic 486 support) if that helped to keep the 486 alive. Eventually we may choose to drop 486 support after all, but CMPXCHG8B alone seems too small a reason to me for that to happen right now. NB MIPS R2000 dates back to 1985, solid 4 years before the 486, and we continue supporting it with minimal effort. We do have atomic emulation for userland of course. Maciej