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 077BEC25B75 for ; Fri, 31 May 2024 21:18:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7FDD66B00A3; Fri, 31 May 2024 17:18:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7866A6B00A5; Fri, 31 May 2024 17:18:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5D8C56B00A8; Fri, 31 May 2024 17:18:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 3CAD36B00A3 for ; Fri, 31 May 2024 17:18:29 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id EF384A0D41 for ; Fri, 31 May 2024 21:18:28 +0000 (UTC) X-FDA: 82179954696.16.2DA2418 Received: from out-176.mta0.migadu.com (out-176.mta0.migadu.com [91.218.175.176]) by imf20.hostedemail.com (Postfix) with ESMTP id E310B1C000B for ; Fri, 31 May 2024 21:18:24 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="Ls3C5/08"; spf=pass (imf20.hostedemail.com: domain of oliver.upton@linux.dev designates 91.218.175.176 as permitted sender) smtp.mailfrom=oliver.upton@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717190305; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=b4Xmi0701V1mOSvq8yprUubnI972AbFWvRE29wJdk78=; b=wNg6oXWSON99wJSnGY5UIrySNCxnMVtQQxTIBR132GLQzI0fhD4+quR8I5LKgiPolXuhN9 8JK69gliryLVyOq7VnzGA/EG2p6MRtN9wF0kioX1hnhDammUQlv8l/LySnXi8izJcm2DVZ ASEceVO1zDxqikc7fD7ssImgGCcSxSs= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717190305; a=rsa-sha256; cv=none; b=NfhIh+qT9NPtDmehNdOtqs9iXKTkRjiMwpOQ3pWEBrGD9n7kzIJBuq6MEHttaWhH53Px94 CI69f6B+QYyCvjs3/3vjVvmxWVNz+vqGOzvFDLiPuiXW1QbshK8VMXmaOEGBB1r3+sySY4 Z9+bL66AWC/GPo1i2w79VlJ74EQLSII= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="Ls3C5/08"; spf=pass (imf20.hostedemail.com: domain of oliver.upton@linux.dev designates 91.218.175.176 as permitted sender) smtp.mailfrom=oliver.upton@linux.dev; dmarc=pass (policy=none) header.from=linux.dev X-Envelope-To: yuzhao@google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1717190302; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=b4Xmi0701V1mOSvq8yprUubnI972AbFWvRE29wJdk78=; b=Ls3C5/08/280zRJqgHSiEjY525Nc+6AHW21VTOJinn6gvpWo5wGpHRdfxPSCAblARNzCTk Ef8yPQJkMIbUZrU0gLqIxyh5em+aap01i8qUkndBnnlYA3LWYTDaFt+T56XGowNC6n0gMV 1xZHPusSMv7Np2WADZqnpp/2B0dMfIM= X-Envelope-To: jthoughton@google.com X-Envelope-To: akpm@linux-foundation.org X-Envelope-To: pbonzini@redhat.com X-Envelope-To: aou@eecs.berkeley.edu X-Envelope-To: ankita@nvidia.com X-Envelope-To: anup@brainfault.org X-Envelope-To: atishp@atishpatra.org X-Envelope-To: axelrasmussen@google.com X-Envelope-To: maobibo@loongson.cn X-Envelope-To: catalin.marinas@arm.com X-Envelope-To: dmatlack@google.com X-Envelope-To: rientjes@google.com X-Envelope-To: chenhuacai@kernel.org X-Envelope-To: james.morse@arm.com X-Envelope-To: corbet@lwn.net X-Envelope-To: maz@kernel.org X-Envelope-To: mpe@ellerman.id.au X-Envelope-To: npiggin@gmail.com X-Envelope-To: palmer@dabbelt.com X-Envelope-To: paul.walmsley@sifive.com X-Envelope-To: rananta@google.com X-Envelope-To: ryan.roberts@arm.com X-Envelope-To: seanjc@google.com X-Envelope-To: shahuang@redhat.com X-Envelope-To: shuah@kernel.org X-Envelope-To: suzuki.poulose@arm.com X-Envelope-To: zhaotianrui@loongson.cn X-Envelope-To: will@kernel.org X-Envelope-To: yuzenghui@huawei.com X-Envelope-To: kvm-riscv@lists.infradead.org X-Envelope-To: kvm@vger.kernel.org X-Envelope-To: kvmarm@lists.linux.dev X-Envelope-To: linux-arm-kernel@lists.infradead.org X-Envelope-To: linux-doc@vger.kernel.org X-Envelope-To: linux-kernel@vger.kernel.org X-Envelope-To: linux-kselftest@vger.kernel.org X-Envelope-To: linux-mips@vger.kernel.org X-Envelope-To: linux-mm@kvack.org X-Envelope-To: linux-riscv@lists.infradead.org X-Envelope-To: linuxppc-dev@lists.ozlabs.org X-Envelope-To: loongarch@lists.linux.dev Date: Fri, 31 May 2024 21:18:12 +0000 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: Yu Zhao Cc: James Houghton , Andrew Morton , Paolo Bonzini , Albert Ou , Ankit Agrawal , Anup Patel , Atish Patra , Axel Rasmussen , Bibo Mao , Catalin Marinas , David Matlack , David Rientjes , Huacai Chen , James Morse , Jonathan Corbet , Marc Zyngier , Michael Ellerman , Nicholas Piggin , Palmer Dabbelt , Paul Walmsley , Raghavendra Rao Ananta , Ryan Roberts , Sean Christopherson , Shaoqin Huang , Shuah Khan , Suzuki K Poulose , Tianrui Zhao , Will Deacon , Zenghui Yu , kvm-riscv@lists.infradead.org, kvm@vger.kernel.org, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mips@vger.kernel.org, linux-mm@kvack.org, linux-riscv@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, loongarch@lists.linux.dev Subject: Re: [PATCH v4 2/7] mm: multi-gen LRU: Have secondary MMUs participate in aging Message-ID: References: <20240529180510.2295118-1-jthoughton@google.com> <20240529180510.2295118-3-jthoughton@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Stat-Signature: 1zb7kk5xdupcrd4o4ao6tuahk5r78647 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: E310B1C000B X-HE-Tag: 1717190304-435279 X-HE-Meta: U2FsdGVkX1+fG4VykSQAEkBtg2eDIofQH21zF7BijSRba+rGqqAR3x2AT8aPWZOUxzGdqgok1PUMsRcaRu19emD0dCwi/RKmIqf5Y+ZMS5XCE9OkNCxt5l5hQMj61Dh4yafpoSe2I/dO4NFMNQUpxZWDLLcs1yjmDmIpplaIERgzIZnctQuy/9B6nBpWZieixs9klY/wgu/uA132uN12SUTQLfKvcvT1R00he06YTCmAyvyMlMLiXbuai3svN85KNEnvHuOuK+fEdp96TReuUrqQ5CgpTYaeHjIOgwK1G3yWKWt9tfxvKHGcXXiBuHfiO2PCHWKViPz9T47qCmF+6I060CgLwyqP9dq4uLRnbUJwcemIvVsvaYbDXNg2xinQ2KQEpNT0s6tA8QPzJhYpxU1RzT1YTi1bxJ4UzVeq5uR0Hk/4KoIK26B4XReu8Ue+UV2yjPHaZXdbXZdEHb0dxcaUhH67PaPWKB+xO9GgTO3FDTiRchknl22dB2SyI272v9SRlVaQS+DJryqbZAH6Yd7xX5CC/vh2F5BoBL8l+EsVafcBsoIDNrFelKeP4upfVKnJdhcarj26wO9dhhayQHUI5qfCWiJKn4qkmn239+oGb6aNN64lHZ+mtc0y77QFge+uGRoIC0gxkY6skZtdGCmn9hOy9q/11QDzS4OlM6g9z7rOOg0/Fbb38SCYBPQhEUbOuOPxsWzJy+A/0g/y05UPjmAjkc9P7pG6+LVTZzaFI8GknncMFFaIGzZg7CgF1WwooacdgX8vRU1c42JdW6SGNdVG6mSEzio9+NfV0amyKT/8PcuowgRAIhQEneBtPkc470G4Qni02p17OhnYkiTximmtaUbIsT+HlTFfJlS9KJcDMcUOtM9bk2G2PNb2LjygLdtOfqB+zrfn5AqnwXpEOabPO81oCD/QspyyC2mfHnbXwMP7/dgCt81+8AEd4lCP2Q0APiDjexBYC0z fFTpw0AE S0Y5BFiwf4mf0fOFYlcmMxNG4jPnlcPmc+oq1RNVDJRIP2V0/ponjH6259yrlPZMjtamYlt+/0DzyaZ2kl0U+dt6w4FZSIqrX0CBdI3zs8sKV4A7uWX/wwtTfKg== 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: List-Subscribe: List-Unsubscribe: On Fri, May 31, 2024 at 02:31:17PM -0600, Yu Zhao wrote: > On Fri, May 31, 2024 at 1:24 AM Oliver Upton wrote: [...] > > Grabbing the MMU lock for write to scan sucks, no argument there. But > > can you please be specific about the impact of read lock v. RCU in the > > case of arm64? I had asked about this before and you never replied. > > > > My concern remains that adding support for software table walkers > > outside of the MMU lock entirely requires more work than just deferring > > the deallocation to an RCU callback. Walkers that previously assumed > > 'exclusive' access while holding the MMU lock for write must now cope > > with volatile PTEs. > > > > Yes, this problem already exists when hardware sets the AF, but the > > lock-free walker implementation needs to be generic so it can be applied > > for other PTE bits. > > Direct reclaim is multi-threaded and each reclaimer can take the mmu > lock for read (testing the A-bit) or write (unmapping before paging > out) on arm64. The fundamental problem of using the readers-writer > lock in this case is priority inversion: the readers have lower > priority than the writers, so ideally, we don't want the readers to > block the writers at all. So we already have this sort of problem of stage-2 fault handling v. secondary MMU invalidations, which is why I've been doubtful of the perceived issue. In fact, I'd argue that needing to wait for faults is worse than aging participation since those can be trivially influenced by userspace/guest. In any case, we shouldn't ever be starved since younger readers cannot enter the critical section with a pending writer. > As I said earlier, I prefer we drop the arm64 support for now, but I > will not object to taking the mmu lock for read when clearing the > A-bit, as long as we fully understand the problem here and document it > clearly. I'd be convinced of this if there's data that shows read lock acquisition is in fact consequential. Otherwise, I'm not sure the added complexity of RCU table walkers (per my statement above) is worth the effort / maintenance burden. -- Thanks, Oliver