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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E3C0EC00140 for ; Tue, 26 Jul 2022 18:04:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239692AbiGZSEE (ORCPT ); Tue, 26 Jul 2022 14:04:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56830 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232585AbiGZSED (ORCPT ); Tue, 26 Jul 2022 14:04:03 -0400 Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1533827CC5 for ; Tue, 26 Jul 2022 11:04:02 -0700 (PDT) Received: by mail-pg1-x52b.google.com with SMTP id s206so13797856pgs.3 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=h0tCvyrB4Dk+UtWHD6r+ED5cP68na0Q9/kX9Xj90Z8CG77aODWnlw8C2cj5IIXySQv 1ose7EUUtpj9IrEK5xxIiQr8WNySP++zKle0bFQitCvHC0L21h3kuqkLbd2D3DTvXz39 YViPzB88mLgXCFoqBTYleNgfK91mWMCEg0qIlkBqMMj8o3OfxCowwfXj5m3c7vDz/gnV nVJ3XB/QGzzYkkBZlaMYZcRo9fHVGFPqN+8IV5v27tNNjeSu67EK8iCePrU3bm0XX70f ZglqXfAnMpJ8Orfid4U8dslHhgDnaHXlrmzUWteSMEZjnrWfZYUawVQMya+YU8zVwDhD qOMw== X-Gm-Message-State: AJIora+Rfh1PfefeJswQsJdDE4tNTFhuyXe4xCCIakT13ru5OlhlLz7y huWHSwmCxO2Dc9z4lRMrQpWGKA== 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-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.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.