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 8EDDDC433F5 for ; Thu, 28 Apr 2022 23:49:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AAD9D6B0071; Thu, 28 Apr 2022 19:49:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A44926B0072; Thu, 28 Apr 2022 19:49:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8B0906B0073; Thu, 28 Apr 2022 19:49:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id 746E16B0071 for ; Thu, 28 Apr 2022 19:49:47 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 3B19F25C35 for ; Thu, 28 Apr 2022 23:49:47 +0000 (UTC) X-FDA: 79407932814.03.6CDAA18 Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com [209.85.128.42]) by imf02.hostedemail.com (Postfix) with ESMTP id 569AA80067 for ; Thu, 28 Apr 2022 23:49:43 +0000 (UTC) Received: by mail-wm1-f42.google.com with SMTP id 125-20020a1c1983000000b003941f354c62so64109wmz.0 for ; Thu, 28 Apr 2022 16:49:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=focMG0Yvzu8kTNlJIkjfWrJiugje96+mCpIttRqo5P4=; b=GOeTnHyfLUj1kYuuIm0Y/SV6rdbaURUuZyug5U8+bM9txNVDB4zqvMsTo6LgWxqqJ+ EJzVOKlCGbXzZnVXdg3zImUfxT1mhWA8cbxLRGVt1mE5eBxCAY3hnU4fMZFKFe1/ysTG cyomFq/31PJ7L9dLLImNGTzmHFLpGkzqWJGCsZd6ESc2YMwmrym/vaV+ntsJIKN6uPzN GHJN6ZJmWTueQxTkthcuYUVcXcDsF4uUX/S+zj4KBcwgIjmuet5DXc3NMlNVPJ+MF4Jl g76wI45mkRhG8Ow9F+ienA/5IabcbdIA62pAqypAHshKR/CNShI7i+XFMGHcSQdqfi8n ZW7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=focMG0Yvzu8kTNlJIkjfWrJiugje96+mCpIttRqo5P4=; b=ACdnJYPUPiou2Lx2amt1TeuxFGpIAFGDdExb118RwRaa/gtK01gIrGiQYH8ilGu14t VvB9ei8O17VDMsy++8fSgPN2+2Hr34OSVfFEQsO53H5bUMyqzKEU71UISY9RlNBd3YK9 xTrgvVxU3k8t+n+HMSueXxpdcVKIPURqVf92uTQs9rQKs+xBkdIW9T4QBLv/DArVYowV XVsECZJL2nRvwn9VwBGxpMS8Btrs/jpKMSbKgp6Lf8JlHdzGX0Snj9uLiSjmHU1hJcp9 PIiqIJ49/CPGw+MIQRofXXAFO4BzY8gALGkPL65L18rHY/6SUdf8XsUY5ukeQNypzQIm FYeg== X-Gm-Message-State: AOAM532qmxX7cXAMWizFkQHoAfHPVeLfkeYQOewFpeUqiA02esWaeKv0 4UywMJ2xAe7b091+gYL1p1x75RBz6dq5gxwRPfzoUg== X-Google-Smtp-Source: ABdhPJya8b5HEmPINhPN/otjpFgAZMsVFO+BsikAPMu9LghWg6ZEVzzp+YtbjdBMxFE0lABxkDoCV9sNN45FlpkElhQ= X-Received: by 2002:a05:600c:1c88:b0:394:dfa:917f with SMTP id k8-20020a05600c1c8800b003940dfa917fmr536458wms.27.1651189785285; Thu, 28 Apr 2022 16:49:45 -0700 (PDT) MIME-Version: 1.0 References: <20220426053904.3684293-1-yosryahmed@google.com> <20220426053904.3684293-5-yosryahmed@google.com> In-Reply-To: From: Yosry Ahmed Date: Thu, 28 Apr 2022 16:49:09 -0700 Message-ID: Subject: Re: [PATCH v3 4/6] KVM: arm64/mmu: count KVM page table pages in pagetable stats To: Oliver Upton Cc: Sean Christopherson , Huacai Chen , Aleksandar Markovic , Anup Patel , Atish Patra , Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Andrew Morton , Johannes Weiner , Michal Hocko , Roman Gushchin , Shakeel Butt , James Morse , Catalin Marinas , Shameer Kolothum , Marc Zyngier , Alexandru Elisei , Suzuki K Poulose , linux-mips@vger.kernel.org, kvm@vger.kernel.org, kvm-riscv@lists.infradead.org, Linux Kernel Mailing List , linux-fsdevel@vger.kernel.org, Linux-MM , cgroups@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=GOeTnHyf; spf=pass (imf02.hostedemail.com: domain of yosryahmed@google.com designates 209.85.128.42 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspam-User: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 569AA80067 X-Stat-Signature: dyqxcia7emqwe7g8yyb8hmuub47cnh17 X-HE-Tag: 1651189783-978520 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 Thu, Apr 28, 2022 at 10:45 AM Oliver Upton wrote: > > On Tue, Apr 26, 2022 at 12:27:57PM -0700, Yosry Ahmed wrote: > > > What page tables do we want to account? KVM on ARM manages several page > > > tables. > > > > > > For regular KVM, the host kernel manages allocations for the hyp stage 1 > > > tables in addition to the stage 2 tables used for a particular VM. The > > > former is system overhead whereas the latter could be attributed to a > > > guest VM. > > > > Honestly I would love to get your input on this. The main motivation > > here is to give users insights on the kernel memory usage on their > > system (or in a cgroup). We currently have NR_PAGETABLE stats for > > normal kernel page tables (allocated using > > __pte_alloc_one()/pte_free()), this shows up in /proc/meminfo, > > /path/to/cgroup/memory.stat, and node stats. The idea is to add > > NR_SECONDARY_PAGETABLE that should include the memory used for kvm > > pagetables, which should be a separate category (no overlap). What > > gets included or not depends on the semantics of KVM and what exactly > > falls under the category of secondary pagetables from the user's pov. > > > > Currently it looks like s2 page table allocations get accounted to > > kmem of memory control groups (GFP_KERNEL_ACCOUNT), while hyp page > > table allocations do not (GFP_KERNEL). So we could either follow this > > and only account s2 page table allocations in the stats, or make hyp > > allocations use GFP_KERNEL_ACCOUNT as well and add them to the stats. > > Let me know what you think. > > I think it is reasonable to just focus on stage 2 table allocations and > ignore all else. As Marc pointed out it isn't workable in other > contexts anyway (pKVM), and keeps the patch tidy too. > > GFP_KERNEL_ACCOUNT for hyp allocations wouldn't make sense, as it is > done at init to build out the system page tables for EL2. Thanks so much for the insights, will send out v4 according to our discussion. > > -- > Thanks, > Oliver