linux-kernel - Re: [PATCH v6 1/4] mm: add NR_SECONDARY_PAGETABLE to count secondary page table uses.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20220817102408.7b048f198a736f053ced2862@linux-foundation.org>
Date:   Wed, 17 Aug 2022 10:24:08 -0700
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     Yosry Ahmed <yosryahmed@...gle.com>
Cc:     Tejun Heo <tj@...nel.org>, Johannes Weiner <hannes@...xchg.org>,
        Zefan Li <lizefan.x@...edance.com>,
        Marc Zyngier <maz@...nel.org>,
        James Morse <james.morse@....com>,
        Alexandru Elisei <alexandru.elisei@....com>,
        Suzuki K Poulose <suzuki.poulose@....com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Sean Christopherson <seanjc@...gle.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>,
        Joerg Roedel <joro@...tes.org>,
        Michal Hocko <mhocko@...nel.org>,
        Roman Gushchin <roman.gushchin@...ux.dev>,
        Shakeel Butt <shakeelb@...gle.com>,
        Oliver Upton <oupton@...gle.com>, Huang@...gle.com,
        Shaoqin <shaoqin.huang@...el.com>, cgroups@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        kvmarm@...ts.cs.columbia.edu, kvm@...r.kernel.org,
        linux-mm@...ck.org
Subject: Re: [PATCH v6 1/4] mm: add NR_SECONDARY_PAGETABLE to count
 secondary page table uses.

On Tue, 28 Jun 2022 22:09:35 +0000 Yosry Ahmed <yosryahmed@...gle.com> wrote:

> We keep track of several kernel memory stats (total kernel memory, page
> tables, stack, vmalloc, etc) on multiple levels (global, per-node,
> per-memcg, etc). These stats give insights to users to how much memory
> is used by the kernel and for what purposes.
> 
> Currently, memory used by kvm mmu is not accounted in any of those
> kernel memory stats. This patch series accounts the memory pages
> used by KVM for page tables in those stats in a new
> NR_SECONDARY_PAGETABLE stat. This stat can be later extended to account
> for other types of secondary pages tables (e.g. iommu page tables).
> 
> KVM has a decent number of large allocations that aren't for page
> tables, but for most of them, the number/size of those allocations
> scales linearly with either the number of vCPUs or the amount of memory
> assigned to the VM. KVM's secondary page table allocations do not scale
> linearly, especially when nested virtualization is in use.
> 
> >From a KVM perspective, NR_SECONDARY_PAGETABLE will scale with KVM's
> per-VM pages_{4k,2m,1g} stats unless the guest is doing something
> bizarre (e.g. accessing only 4kb chunks of 2mb pages so that KVM is
> forced to allocate a large number of page tables even though the guest
> isn't accessing that much memory). However, someone would need to either
> understand how KVM works to make that connection, or know (or be told) to
> go look at KVM's stats if they're running VMs to better decipher the stats.
> 
> Furthermore, having NR_PAGETABLE side-by-side with NR_SECONDARY_PAGETABLE
> is informative. For example, when backing a VM with THP vs. HugeTLB,
> NR_SECONDARY_PAGETABLE is roughly the same, but NR_PAGETABLE is an order
> of magnitude higher with THP. So having this stat will at the very least
> prove to be useful for understanding tradeoffs between VM backing types,
> and likely even steer folks towards potential optimizations.
> 
> The original discussion with more details about the rationale:
> https://lore.kernel.org/all/87ilqoi77b.wl-maz@kernel.org
> 
> This stat will be used by subsequent patches to count KVM mmu
> memory usage.

Nits and triviata:

> --- a/Documentation/filesystems/proc.rst
> +++ b/Documentation/filesystems/proc.rst
> @@ -977,6 +977,7 @@ Example output. You may not have all of these fields.
>      SUnreclaim:       142336 kB
>      KernelStack:       11168 kB
>      PageTables:        20540 kB
> +    SecPageTables:         0 kB
>      NFS_Unstable:          0 kB
>      Bounce:                0 kB
>      WritebackTmp:          0 kB
> @@ -1085,6 +1086,9 @@ KernelStack
>                Memory consumed by the kernel stacks of all tasks
>  PageTables
>                Memory consumed by userspace page tables
> +SecPageTables
> +              Memory consumed by secondary page tables, this currently
> +	      currently includes KVM mmu allocations on x86 and arm64.

Something happened to the whitespace there.

> +			     "Node %d SecPageTables:  %8lu kB\n"
> ...
> +			     nid, K(node_page_state(pgdat, NR_SECONDARY_PAGETABLE)),

The use of "sec" in the user-facing changes and "secondary" in the
programmer-facing changes is irksome.  Can we be consistent?  I'd
prefer "secondary" throughout.