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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 6015FC04A68 for ; Tue, 26 Jul 2022 18:05:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=AxYYfuWMORdSIwYMuKBXDFRzBKjJmgB9GRfxjRi1A7E=; b=gCaNGFkWbX71O7 zp3npEa1guLQ32LWUDyqw+vf1rAbU3knGsdv6a/5No6tQnADo+0BJ1ZB87RTO0ZUBHPiMJe1Gge4y VcGIZ5IOvg5ed8xnqu5O99CCIDlNdvP3lgdS833XNLZwWKhsGioEek9sbC414/KIwirisKHuRprDo fdp0+XZjqfsBznA6GJHlG909kIigg1DfTbO1q2mp7zeOgHcF+gaUcU3B/nlSkl65lRROTL68t4Lwc Ns8mPQiJED3REzkYL9mvqXVdr8TCiiRbXRNFyRfzrtyDFdshbj86pWir/QBHOuVJuIcuJGg8jAhiM SC5fplQ7K6nOAlNFQvpA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oGOue-001uEU-VE; Tue, 26 Jul 2022 18:04:09 +0000 Received: from mail-pf1-x434.google.com ([2607:f8b0:4864:20::434]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oGOub-001u9n-KQ for linux-arm-kernel@lists.infradead.org; Tue, 26 Jul 2022 18:04:07 +0000 Received: by mail-pf1-x434.google.com with SMTP id c139so13922265pfc.2 for ; Tue, 26 Jul 2022 11:04:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=jhdzRZUAOMTnCV/vW7pBqgsIJIfjNF/pYz/pr69nELI=; b=ptd/st7Qx1CEBd6nXVmofsETHlqEG5YHpXzAHoHWMHaxaLqLQRwhFD8DrqTGh313HP IhmbQkRu0orlHojxKg773kXGBU90oYKT/i2R8RIWnvFI/6XWjOJwk/NLwViv8Eohzc71 0u1CxuXzpRO+SKGj4rghNIk24TUgiK6N5EMVsSWyZucFXHEwqrREOemBmRGcO21GlJv+ BHPELPoCCxRkiXuj0q4tx3KOjfEFuVK8aaztJ92oE13l2AqbgmCf3A+ZhaLe8cNklHQ/ gZtTgJkayqLParwE71HzxpR93H5vfYmTwDBbX/RNcN9pr066yekhsOaOlX87QwoQCIMQ U+yA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=jhdzRZUAOMTnCV/vW7pBqgsIJIfjNF/pYz/pr69nELI=; b=4bz6DqdjdMm/xbF4rSfMla8zPlAxnur4NMqegfamLRL6rv4nOSXJzTS6kyRGAcmXyl N+YXauFa4wIGA6wEup1kzcH/9KWpgjIbjlSNyZBUWd5BCCYWm/+3MockIThwk0xdMkqS ZtYlan6+99SDzKorr/OP3+w7rnYuFI5pdVPe3s/VtWDjDcEK8YjpeLi/jCiHRwUt0JsA zjnHB/Im0oPHEgTjyrpQoj/VHuOnR/aClmOZzYXc+U7muzCheqAUKHA7OL+vibHlTShg BqoZQy380JmaENaGZ+ZvuT7qWBlPhNh5uquQMqSLOr96OzUF1m7rs7FUHJCjvIie2Eay QbVg== X-Gm-Message-State: AJIora88F1kJjqsVfYz6bKt4EeOLTtaMRj2TV5dNmdH/bsDCtA8OghCj V8mcE8N+joF64zi0Q/CD3kfE3Q== X-Google-Smtp-Source: AGRyM1uKR6/hOW723JGGrSJD19noCDp0+vmsYlXYClvLLQpEtHJHtnV8BUou5cQTx2omdbkUrVjS2Q== X-Received: by 2002:a05:6a00:1c54:b0:52b:a70e:8207 with SMTP id s20-20020a056a001c5400b0052ba70e8207mr18313321pfw.48.1658858641379; Tue, 26 Jul 2022 11:04:01 -0700 (PDT) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id f4-20020a170902860400b0016be0d5483asm11848682plo.252.2022.07.26.11.04.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 Jul 2022 11:04:00 -0700 (PDT) Date: Tue, 26 Jul 2022 18:03:57 +0000 From: Sean Christopherson To: Mingwei Zhang Cc: Yosry Ahmed , Tejun Heo , Johannes Weiner , Zefan Li , Marc Zyngier , James Morse , Alexandru Elisei , Suzuki K Poulose , Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Andrew Morton , Michal Hocko , Roman Gushchin , Shakeel Butt , Oliver Upton , cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v4 3/4] KVM: x86/mmu: count KVM mmu usage in secondary pagetable stats. Message-ID: References: <20220429201131.3397875-1-yosryahmed@google.com> <20220429201131.3397875-4-yosryahmed@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220726_110405_704090_CA8A20B8 X-CRM114-Status: GOOD ( 19.80 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Jul 22, 2022, Mingwei Zhang wrote: > On Fri, Apr 29, 2022, Yosry Ahmed wrote: > > Count the pages used by KVM mmu on x86 for in secondary pagetable stats. > > > > For the legacy mmu, accounting pagetable stats is combined KVM's > > existing for mmu pages in newly introduced kvm_[un]account_mmu_page() > > helpers. > > > > For tdp mmu, introduce new tdp_[un]account_mmu_page() helpers. That > > combines accounting pagetable stats with the tdp_mmu_pages counter > > accounting. > > > > tdp_mmu_pages counter introduced in this series [1]. This patch was > > rebased on top of the first two patches in that series. > > > > [1]https://lore.kernel.org/lkml/20220401063636.2414200-1-mizhang@google.com/ > > > > Signed-off-by: Yosry Ahmed > > --- > > It looks like there are two metrics for mmu in x86: one for shadow mmu > and the other for TDP mmu. Is there any plan to merge them together? There aren't two _separate_ metrics per se, rather that the TDP MMU (intentionally) doesn't honor KVM_SET_NR_MMU_PAGES, nor does it play nice the the core mm shrinkers. Thus, the TDP MMU doesn't udpate kvm_mod_used_mmu_pages(), which feeds into both of those things. Long term, I don't think the TDP MMU will ever honor KVM_SET_NR_MMU_PAGES. That particular knob predates proper integration with memcg and probably should be deprecated. As for supporting shrinkers in the TDP MMU, it's unclear whether or not that's truly necessary. And until mmu_shrink_scan() is made a _lot_ smarter, it's somewhat of a moot point because KVM's shrinker implementation is just too naive for it to be a net positive, e.g. it tends to zap upper level entries and wipe out large swaths of KVM's page tables. KVM_SET_NR_MMU_PAGES uses the same naive algorithm, so it's not any better. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel