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 1CC8FC25B75 for ; Fri, 31 May 2024 21:10:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7F8476B00A9; Fri, 31 May 2024 17:10:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7A78F6B00AB; Fri, 31 May 2024 17:10:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 66F4A6B00AC; Fri, 31 May 2024 17:10:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 490AC6B00A9 for ; Fri, 31 May 2024 17:10:19 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id EF425A127F for ; Fri, 31 May 2024 21:10:18 +0000 (UTC) X-FDA: 82179934116.01.4A6C108 Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) by imf22.hostedemail.com (Postfix) with ESMTP id 1FC53C0016 for ; Fri, 31 May 2024 21:10:16 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=22N+AV+6; spf=pass (imf22.hostedemail.com: domain of dmatlack@google.com designates 209.85.221.44 as permitted sender) smtp.mailfrom=dmatlack@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717189817; a=rsa-sha256; cv=none; b=HGFssskff3YlVRYfRNWS0JiUqGJ5ZSYkEzoMsd6MbBHbXfLaxRQuj7qUeFKUgd95tAXkjw /NB62x/CuZn9aWqwigw36Uzy7PkBea91oldccctECFQSN3WPbVbonRa2rYyTU1SeGxIcnL oFWMKNxsiFx9h5uJeFZq4H8NrnsaZaI= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=22N+AV+6; spf=pass (imf22.hostedemail.com: domain of dmatlack@google.com designates 209.85.221.44 as permitted sender) smtp.mailfrom=dmatlack@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717189817; 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=N2tq10nFX29kQGqNAS352osxyUaVdPznDkZxoHpHfa8=; b=V1mS52RrS1W549pzV02vADBbcKa33ncOsPdn7Y/sTteyAuaSgWKWXf8ze/ANgNYpuuxVpv ifSXWzNm4sCxHONuXP65HmX4CLg4CajpnA9tnp2Bb4YtBHDb6OIzmdNMqz8khsVfORXR9Y vqS3xtvLou/fTmKIQitu6cjjSSTluUU= Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-35dcff36522so1368486f8f.1 for ; Fri, 31 May 2024 14:10:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1717189816; x=1717794616; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=N2tq10nFX29kQGqNAS352osxyUaVdPznDkZxoHpHfa8=; b=22N+AV+65+24tWVTofpeHUMSSYNo5sXY7PugZzN6ZQ1MPPHa7ThPGX8Z7VIvk3ADnN GXnWbJFWj8CItRZFBvBWmpyzGpiMpmXEWSUVeAlrpBlpiBtUQMgjcyioVXVJBEWagQpC gBxSaQiho0dfd7Z7Noe7THCjGnUaDcPk0ewbBfm8yieo5XVMGFTxThzcu99vX4juANcv X15DU9Qhs42jTP9Rw+RSmJ+8BbqWIbu7/YIdypEIAC+tc51wReftNxGD+g4RSziv00vj KK7fjrsw7zhrBZRuhZwxBFQXaYqaW7VfOkF9/0uaelTZP3zCRnYixfRD+Wn2BQ6lT2oc 4O+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717189816; x=1717794616; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=N2tq10nFX29kQGqNAS352osxyUaVdPznDkZxoHpHfa8=; b=EpaUh9rWXItlHOZaOdi2TLnFqfZrbaq+e49YNLbMhZgJFZPWdYAVWIkd34vJBPJvv0 mQEbtGYUGSFo7RjbDtrfpJMLA7I1u3nNtE6zcwzw81BIOcf7xQcUk25Fe9W3Ndpw6tin 3q+ojGaHSRgCXAXLwp9JmEh24vedq5W/S5lWRYoU2Zq0dxLL5L/dmYUWscKJGja53r+F HJOGI+Jncq4Hnp0LtqYOc1xz4shzoX2QzPdDq36+jUj0ddk8B6uLAQUGNamWJRTuHvSO gW57IgSic8fB8PxM5KwyEicPTxWBtQjsdrMQwi5uBfVTkM2rRyq5wQSRPCoE2V8nd8K0 dRvw== X-Forwarded-Encrypted: i=1; AJvYcCVenfL/dNf4EjuGmPqsQ5NnI8uNB7CSzFZ06iaJ9qG8duXxHlBLXGZbQtyEgM/+LoS8eDhvEb1rXtItlsWIg1XndyQ= X-Gm-Message-State: AOJu0Yxox2v8EqGqk4DYpgNhXmKBXX3TBxgFgU4Kj1m4Y9EpLwG9nIa5 ql63Vhc0YAFVwSsX0yDfwFKpzDpBLFZ7juaMdb2Sei4GYVvZP2+QvWR8Cq9arO7qF8br37MtYPf DI7Af4eOLVQvj2D4Dcn74/4o1E7UTFihI56Wn X-Google-Smtp-Source: AGHT+IGBXgQKGvGpLJLkAZRNkN3pvPdaYlgrwH8luU8wCcE+kb/FtudP+b0UHW6VTmsTqjv8AVqi9KSPou5NOiUNmXY= X-Received: by 2002:a05:6000:1b09:b0:357:ca29:f1ca with SMTP id ffacd0b85a97d-35e0f2869c8mr2259497f8f.32.1717189815401; Fri, 31 May 2024 14:10:15 -0700 (PDT) MIME-Version: 1.0 References: <20240529180510.2295118-1-jthoughton@google.com> <20240529180510.2295118-3-jthoughton@google.com> In-Reply-To: From: David Matlack Date: Fri, 31 May 2024 14:09:49 -0700 Message-ID: Subject: Re: [PATCH v4 2/7] mm: multi-gen LRU: Have secondary MMUs participate in aging To: Yu Zhao Cc: Oliver Upton , James Houghton , Andrew Morton , Paolo Bonzini , Albert Ou , Ankit Agrawal , Anup Patel , Atish Patra , Axel Rasmussen , Bibo Mao , Catalin Marinas , 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 1FC53C0016 X-Stat-Signature: p5nictyr8kgs5piidq4to5thwh69iai5 X-HE-Tag: 1717189816-131726 X-HE-Meta: U2FsdGVkX1/8P6sf2V6JJ8XgETWS2m6kc+GJfCOcdkGH5bkgB88Vhk3V3uGHch+J6IGp8ui1AdEDn5FgwPHusbOm6QYAmKCw8rQ7kSY64i4YmgFpgZpQrGCgWtCLQ4Eoj9mKqO+rukcm+K/iMMMIiOJGAwU8vqQ5fixyrjrAW3/WNBUu/8mv9E1mwEjGSk1KqGaQljSusnVDfQ/ZA1YF8vdabh72LS7qpIADIU6baY3BgQMVyGWMlPDLwNYeUgyzXqRBoUW4/E+LbPn3+cpNrshF2cBLDJwYOJV4+G8tSqowmOaQ7dISXscOD7dBu8vHqKhm5dk+GqtBvQC4xaRLrB8vsKbYYFSICHCPEuv6TfQSSrpemK/zSTRavoZW70nnzxdBaAIy2vF8eiS0id5OxwK6YaLrGKffirnviPrEr6ON7GvXskQ/HQ1MTqJxK1gpfqlgT8DjNMm+rXofdHp6gPg2qXEdgR1TBSylh/f+AZ1tDDjszHqmntyGZL+2fXO2j+7MF/YCu223p+ncta4Gpe4iuKIQT7DoQvOAN7K7isS5v48UewmhsKj4K5XJjqrjpozMmlS3FyaF/R96MSuIHRRxVg6qSWYkwsIa+eAHNJdPozhsZeL9HVWhd1ZXgdSJuPLbiIBJ6L6RynkXjfbivcKXTPWxoI94a7JmwQKBoAMBqaF2Kzr3JcfH1aE0x0O/xi9GxIBHceTwyjgDjByI8jhM/VVjkyAbh8QRJvxg4b4kB/6u1k6bzzIwPdAoto7jzEX+RfLM9edWm4UsJQKBIGQLAZwh/d74l50TPStHjPoOeAxWtvesVcvra14/qsoG8IN4pcGYtafatxqKdpLGX8ASFlPgiuLOeUZaH2D72v52MPJmJtHhP5VHu9VPkDi2oYmN8CQKTm+gimnNssg+6lZFQKL2z5Z+GF8Ey+YmJoxV1m+CtNBCX6HF7SbT9K7WBwNuVUHQJ7doBWHOgAp 1hxpY8YH VAxSMDwXGwHkjLbxb02Ou63haK7WSb5yG3iDa/e24Ea6gVZ0+BLSM3IkLIYwkJAng1z3I/uwDhSamJMODmYLWW4W6DYVpH4pfRcXgz0HgKv8B961yv8LL7cLpMQr6vQvgi4ZI2sW4i0S67ugITgW6Wd0m5PRKNb6xdOkPgNjtVTLBAFKG6+w4/p5HKHx68ZYkfWKpmpf5Y7V1zHksrxVS+TqvS1oFk6NxXmt8fA+PfDVQWdOikXs8052piA== 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 2:06=E2=80=AFPM David Matlack = wrote: > > On Fri, May 31, 2024 at 1:31=E2=80=AFPM Yu Zhao wrote= : > > > > On Fri, May 31, 2024 at 1:24=E2=80=AFAM Oliver Upton wrote: > > > > > > On Wed, May 29, 2024 at 03:03:21PM -0600, Yu Zhao wrote: > > > > On Wed, May 29, 2024 at 12:05=E2=80=AFPM James Houghton wrote: > > > > > > > > > > Secondary MMUs are currently consulted for access/age information= at > > > > > eviction time, but before then, we don't get accurate age informa= tion. > > > > > That is, pages that are mostly accessed through a secondary MMU (= like > > > > > guest memory, used by KVM) will always just proceed down to the o= ldest > > > > > generation, and then at eviction time, if KVM reports the page to= be > > > > > young, the page will be activated/promoted back to the youngest > > > > > generation. > > > > > > > > Correct, and as I explained offline, this is the only reasonable > > > > behavior if we can't locklessly walk secondary MMUs. > > > > > > > > Just for the record, the (crude) analogy I used was: > > > > Imagine a large room with many bills ($1, $5, $10, ...) on the floo= r, > > > > but you are only allowed to pick up 10 of them (and put them in you= r > > > > pocket). A smart move would be to survey the room *first and then* > > > > pick up the largest ones. But if you are carrying a 500 lbs backpac= k, > > > > you would just want to pick up whichever that's in front of you rat= her > > > > than walk the entire room. > > > > > > > > MGLRU should only scan (or lookaround) secondary MMUs if it can be > > > > done lockless. Otherwise, it should just fall back to the existing > > > > approach, which existed in previous versions but is removed in this > > > > version. > > > > > > 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 th= e > > > 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 deferri= ng > > > 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 appl= ied > > > 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. > > > > Using my previous (crude) analogy: puting the bill right in front of > > you (the writers) profits immediately whereas searching for the > > largest bill (the readers) can be futile. > > > > 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. > > FWIW, Google Cloud has been doing proactive reclaim and kstaled-based > aging (a Google-internal page aging daemon, for those outside of > Google) for many years on x86 VMs with the A-bit harvesting > under the write-lock. So I'm skeptical that making ARM64 lockless is > necessary to allow Secondary MMUs to participate in MGLRU aging with > acceptable performance for Cloud usecases. I don't even think it's > necessary on x86 but it's a simple enough change that we might as well > just do it. The obvious caveat here: If MGLRU aging and kstaled aging are substantially different in how frequently they trigger mmu_notifiers, then my analysis may not be correct. I'm hoping Yu you can shed some light on that. I'm also operating under the assumption that Secondary MMUs are only participating in aging, and not look-around (i.e. what is implemented in v4). > > I suspect under pathological conditions (host under intense memory > pressure and high rate of reclaim occurring) making A-bit harvesting > lockless will perform better. But under such conditions VM performance > is likely going to suffer regardless. In a Cloud environment we deal > with that through other mechanisms to reduce the rate of reclaim and > make the host healthy. > > For these reasons, I think there's value in giving users the option to > enable Secondary MMUs participation MGLRU aging even when A-bit > test/clearing is not done locklessly. I believe this was James' intent > with the Kconfig. Perhaps a default-off writable module parameter > would be better to avoid distros accidentally turning it on? > > If and when there is a usecase for optimizing VM performance under > pathological reclaim conditions on ARM, we can make it lockless then.