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 F03D1C61DA4 for ; Thu, 23 Feb 2023 05:26:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 260FD6B0074; Thu, 23 Feb 2023 00:26:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1EAA56B0075; Thu, 23 Feb 2023 00:26:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 063AB6B0078; Thu, 23 Feb 2023 00:26:21 -0500 (EST) 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 E5FBF6B0074 for ; Thu, 23 Feb 2023 00:26:20 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 9BE78AB736 for ; Thu, 23 Feb 2023 05:26:20 +0000 (UTC) X-FDA: 80497420920.09.27A8AA8 Received: from mail-vs1-f45.google.com (mail-vs1-f45.google.com [209.85.217.45]) by imf02.hostedemail.com (Postfix) with ESMTP id C339880007 for ; Thu, 23 Feb 2023 05:26:18 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=ebfMrTiO; spf=pass (imf02.hostedemail.com: domain of yuzhao@google.com designates 209.85.217.45 as permitted sender) smtp.mailfrom=yuzhao@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677129978; a=rsa-sha256; cv=none; b=PhSE+YFmogE52zrk/0mR8uTU4s9G5hZLFIvdyF/PNtupbCj+XLl29zPY8ItPRzAO/p7oNo TTRl5xTLwL0f2fsHOCIyVA67fN1ffSrfAM8AwKq5sHd2PSwuygcd80MgOf1jdwawoOcjbO rlybRO4TEwCaeKh9OLBGQLdL8RWeaFU= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=ebfMrTiO; spf=pass (imf02.hostedemail.com: domain of yuzhao@google.com designates 209.85.217.45 as permitted sender) smtp.mailfrom=yuzhao@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=1677129978; 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=AXEnUJIuw3DsBBpeEas97UQaCI4+fKGVwu8RQPcIlxs=; b=pxUORykI1rk8kib9P5bNHTdnJkaNLIjiAsVvP+nHy6PJY4omRLnI0SRNoQHtj/moNmZx6O Eb+29UYg3TZnNkr9baetQUm8kdNfaeUujNgRJUY5CYXOckAzA7oF06B6h2NSJn/+OvQIn7 ThycMD+qK2Dv7Ah2CPEqenphq+9RSMg= Received: by mail-vs1-f45.google.com with SMTP id m10so11329380vso.4 for ; Wed, 22 Feb 2023 21:26:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; 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=AXEnUJIuw3DsBBpeEas97UQaCI4+fKGVwu8RQPcIlxs=; b=ebfMrTiO8jVZApxkACFGkW19OKcseaGjzh5HjIfu8MAU62l8YkK9wYnBFkU6I+6zuE AUDCEHsZSZ9mbCKKWNPTplXuqS87aYdUMgEd5/HJTFPzZF9uHLGfh+f//SGkFgG2WUUC VMrPZXwgvdZQ0a9Rdfoin9rPnC9lwtXHaGCdiIAVtUZ+zDzePE60bEA2n80H6qz2mPub YZRSOEb//hMVhNQrFI5fjyJOTZ5EPIveLNi+6mlZv8sUqb9Y6C+ziwSJjuW7/BuocHT5 ypJ99wrjoFqAACPuG1lbl4B3N9wqDvRcpL/jBCfwY1kMxbLPNuarGmvnmO4vjdaXxv4a SkyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=AXEnUJIuw3DsBBpeEas97UQaCI4+fKGVwu8RQPcIlxs=; b=FPfpqPvzS1CI8aION/XRqgNI6KIN1JcKilzmShdIk4DtfBIM8icVJPDftH0jzJGV+r ukapZu9gXbZVzel6VE2rCXKU8TMHOHw2xlAqu9w4mzbChjDHKfvTizGIRgOjHEgyiQen VHePdN7sbLeEYRNI8tPhOZCCYBdvlaKGtwPLrlT6+pDP5m+kafUPL5t2I7ZWwuPZnl9/ 3EVSKvTEGYSEypoWVoHo5dnIwkGE6D4+uPGOQygLgktv80YQJSx5Rd/41tUiVbfMPOj1 U6JwcT7XO3+HjS33IBFf4bEvZo7RoZUvSzj5dT3g2uJ9uFUyl7w2bMY1d+HWqRXfpKIf T2dA== X-Gm-Message-State: AO0yUKUfugnCI4R6ZPDeNhmASToKze/4yhxB+/yHyapu8jibYhV4X8L6 iDAE+3626nJ8fk3TpdNUS5N3Q2NOG14J/uEdNc0qBQ== X-Google-Smtp-Source: AK7set/r/f8pGhkIjYGiLVLtcsnWRFxpAmGZdfZxTguMU1aVP5zVqu1WLV5ZRnN+vLq9szVFT6NHenS4YuDGWsM46AY= X-Received: by 2002:a05:6102:108f:b0:41e:d8b5:ee40 with SMTP id s15-20020a056102108f00b0041ed8b5ee40mr553492vsr.26.1677129977589; Wed, 22 Feb 2023 21:26:17 -0800 (PST) MIME-Version: 1.0 References: <20230217041230.2417228-1-yuzhao@google.com> <20230217041230.2417228-4-yuzhao@google.com> In-Reply-To: From: Yu Zhao Date: Wed, 22 Feb 2023 22:25:41 -0700 Message-ID: Subject: Re: [PATCH mm-unstable v1 3/5] kvm/arm64: add kvm_arch_test_clear_young() To: Sean Christopherson Cc: Oliver Upton , Andrew Morton , Paolo Bonzini , Jonathan Corbet , Michael Larabel , kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, x86@kernel.org, linux-mm@google.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: C339880007 X-Rspamd-Server: rspam01 X-Stat-Signature: 7fuiicksw19rcz915ttjuht66mdgn1pq X-HE-Tag: 1677129978-477379 X-HE-Meta: U2FsdGVkX18KzDKcDpTJkkHs8Mqk89E6NJWyvKrRplCRwIKSswP1qkHO56jIPsIU0lJ0NxSmFMCjxxzIdDXLrnJVjnUx9ppqzOCBP1xqW+EZiT+76nC+Mf012yWudqhAYA+IL1M9teAlitJMFAR2AK2odnRCIFyeMrnRUE0CsqjvQL4sbVnDgcnWCz+NzvY1eKNzoK3IDhciu1OMfLexcthIXPdDtKOdICozyxA9/WB/BrZKWta1aC2tUfAkoYFphSxuka3YxE2g9w87fJvyArbdyRGA2nz7MaSYZ+Rb8IO0CJzAvuN3E6BsOa7QN61fI+kVWXI5SRdtcYJ+4X0LHwvDEZrkCSb3aCfzwL3uoN6JsbzdF6hHJupHFC3X7/HoZU4Mttq6wFkpxv/nrdOccrmm1ZvAiBnkc9tgpkA5ukEZp9VY34Vgatmymah/VzudM2/r9Uoa+G17+8RRjQ6ruqXxScPt15GsY9olYUWnfpjFcPZJ/olqelbr63frStrB/4q9FQ1EySNSFg0cOwFQxq/VoYIeQX7TLZ4xbXQUlEhE9Bpr7VnzvDeayNb/oVTXTAwAv4j+OS8cqh3V+dy3ED1jiA5rvz5sRPLSC9VkhI0nDpaMklv0YhcgToZWQ8no6+9+fC4s6Y9BUKlFNRiY8LoStKjW6ioS1Bwpt3NJyfZV9IJxGW6TXNm8oLNr8cFIw2/m9Xvdy1Nt/1QY3rCTo6dBDj7WatrQJtjhsOtSOIzMlSdcf4tXzp8c43a6EWCWWToSQFsBVVeu6aAIJRRtIljsX+kQf6tIt4B30dEF4CJ+lcHg2usATWD0P2ajnhPc57wVtLol/JxjHYrdwcinNqq2W8bpusQVV8zLKcM25VZJljhK5p16tefSmGa8YQMMXNnPEwO5+ZTTpRNTtF0c5lKlD4/VNPiBLO21+d1/DEDucD0mMFDPw/jZR8ZXDaiZHz6J+ilZD+zIXg6cQnC I6ObR8Co ZIIMAc2km/hFmQ58AKNUXngw0Ub3ypAr1Casz/tB3ULdDDGOX4EGMzC2ceVBzsUCBSU0pm1yI0G0ng2TsH1Byb0kCrZaVKBSYCD+6YUSjFUgJU3qmxK1k7kaR/s6/ye9VbPivy+TAF71mOCCRS2+LAasVo01Pv9pe7M3y4XZduJUzeLpkbYWmzZBXxCMhb6oH000897NqRPQfTAWbWGq0n/k0txEo5YaOJSVS1w3zD6vw7xOZdS6oKSVUuRDTjZq8XrhfgI8R3P0GI4GFVlsmw+eonWTJHnQ4NXuUZNNHwbQCI0TMVWUqPE9f7sjBfF3hcvv2IrkRBqfjqflJcA+0ypodHgpRxXKzHPIXhuqYIOOlhdW5KR1pmdM/zg== 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, Feb 17, 2023 at 9:00=E2=80=AFAM Sean Christopherson wrote: > > On Fri, Feb 17, 2023, Oliver Upton wrote: > > Hi Yu, > > > > scripts/get_maintainers.pl is your friend for getting the right set of > > emails for a series :) Don't know about others, but generally I would > > prefer to be Cc'ed on an entire series (to gather context) than just an > > individual patch. > > +1 > > > > > On Thu, Feb 16, 2023 at 09:12:28PM -0700, Yu Zhao wrote: > > > This patch adds kvm_arch_test_clear_young() for the vast majority of > > > VMs that are not pKVM and run on hardware that sets the accessed bit > > > in KVM page tables. > > At least for the x86 changes, please read Documentation/process/maintaine= r-tip.rst > and rewrite the changelogs. I see -- will remove "this patch". > > > It relies on two techniques, RCU and cmpxchg, to safely test and clea= r > > > the accessed bit without taking the MMU lock. The former protects KVM > > > page tables from being freed while the latter clears the accessed bit > > > atomically against both the hardware and other software page table > > > walkers. > > > > > > Signed-off-by: Yu Zhao > > > --- > > > arch/arm64/include/asm/kvm_host.h | 7 +++ > > > arch/arm64/include/asm/kvm_pgtable.h | 8 +++ > > > arch/arm64/include/asm/stage2_pgtable.h | 43 ++++++++++++++ > > > arch/arm64/kvm/arm.c | 1 + > > > arch/arm64/kvm/hyp/pgtable.c | 51 ++-------------- > > > arch/arm64/kvm/mmu.c | 77 +++++++++++++++++++++++= +- > > > 6 files changed, 141 insertions(+), 46 deletions(-) > > > > > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/a= sm/kvm_host.h > > > index 35a159d131b5..572bcd321586 100644 > > > --- a/arch/arm64/include/asm/kvm_host.h > > > +++ b/arch/arm64/include/asm/kvm_host.h > > > @@ -1031,4 +1031,11 @@ static inline void kvm_hyp_reserve(void) { } > > > void kvm_arm_vcpu_power_off(struct kvm_vcpu *vcpu); > > > bool kvm_arm_vcpu_stopped(struct kvm_vcpu *vcpu); > > > > > > +/* see the comments on the generic kvm_arch_has_test_clear_young() *= / > > Please eliminate all of these "see the comments on blah", in every case t= hey do > nothing more than redirect the reader to something they're likely already= aware of. > > > > +#define kvm_arch_has_test_clear_young kvm_arch_has_test_clear_young > > > +static inline bool kvm_arch_has_test_clear_young(void) > > > +{ > > > + return IS_ENABLED(CONFIG_KVM) && cpu_has_hw_af() && !is_protected= _kvm_enabled(); > > > +} > > ... > > > Also, I'm at a loss for why we'd need to test if CONFIG_KVM is enabled. > > My expectation is that we should provide an implementation that returns > > false if !CONFIG_KVM, avoiding the need to repeat that bit in every > > single implementation of the function. > > mm/vmscan.c uses kvm_arch_has_test_clear_young(). I have opinions on tha= t, but > I'll hold off on expressing them until there's actual justification prese= nted > somewhere. > > Yu, this series and each patch needs a big pile of "why". I get that the= goal > is to optimize memory oversubscribe, but there needs to be justification = for > why this is KVM only, why nested VMs and !A/D hardware are out of scope, = why yet > another mmu_notifier hook is being added, etc. I totally agree. This is an optimization, not a bug fix. It can't be justified without performance numbers from some common use cases. That burden of proof clearly rests on me -- I will follow up on that. For now, I want to make sure the methodical part is clear: 1. We only have limited resources and we need to prioritize major use cases= . 2. We can only improve one thing at a time and we can't cover everything at the same time. 3. We need to focus on the return on investment and the future. I hope everyone by now agrees with my "the vast majority of VMs ..." assertion. If not, I'm happy to revisit that [1]. If so, the next step would be whether we want to focus on the vast majority first. I think this naturally answers why the nested VMs and !AD h/w are out of scope, at the moment (I didn't spell this out; probably I should in v2). After we have taken the first step, we probably can decide whether there is enough resource and demand to cover the low return on investment part (but complexity but less common use cases). [1] https://lore.kernel.org/linux-mm/20230217041230.2417228-1-yuzhao@google= .com/