• Sourav Panda's avatar
    mm: report per-page metadata information · 15995a35
    Sourav Panda authored
    Today, we do not have any observability of per-page metadata and how much
    it takes away from the machine capacity.  Thus, we want to describe the
    amount of memory that is going towards per-page metadata, which can vary
    depending on build configuration, machine architecture, and system use.
    
    This patch adds 2 fields to /proc/vmstat that can used as shown below:
    
    Accounting per-page metadata allocated by boot-allocator:
    	/proc/vmstat:nr_memmap_boot * PAGE_SIZE
    
    Accounting per-page metadata allocated by buddy-allocator:
    	/proc/vmstat:nr_memmap * PAGE_SIZE
    
    Accounting total Perpage metadata allocated on the machine:
    	(/proc/vmstat:nr_memmap_boot +
    	 /proc/vmstat:nr_memmap) * PAGE_SIZE
    
    Utility for userspace:
    
    Observability: Describe the amount of memory overhead that is going to
    per-page metadata on the system at any given time since this overhead is
    not currently observable.
    
    Debugging: Tracking the changes or absolute value in struct pages can help
    detect anomalies as they can be correlated with other metrics in the
    machine (e.g., memtotal, number of huge pages, etc).
    
    page_ext overheads: Some kernel features such as page_owner
    page_table_check that use page_ext can be optionally enabled via kernel
    parameters.  Having the total per-page metadata information helps users
    precisely measure impact.  Furthermore, page-metadata metrics will reflect
    the amount of struct pages reliquished (or overhead reduced) when
    hugetlbfs pages are reserved which will vary depending on whether hugetlb
    vmemmap optimization is enabled or not.
    
    For background and results see:
    lore.kernel.org/all/20240220214558.3377482-1-souravpanda@google.com
    
    Link: https://lkml.kernel.org/r/20240605222751.1406125-1-souravpanda@google.comSigned-off-by: default avatarSourav Panda <souravpanda@google.com>
    Acked-by: default avatarDavid Rientjes <rientjes@google.com>
    Reviewed-by: default avatarPasha Tatashin <pasha.tatashin@soleen.com>
    Cc: Alexey Dobriyan <adobriyan@gmail.com>
    Cc: Bjorn Helgaas <bhelgaas@google.com>
    Cc: Chen Linxuan <chenlinxuan@uniontech.com>
    Cc: David Hildenbrand <david@redhat.com>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Ivan Babrou <ivan@cloudflare.com>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Jonathan Corbet <corbet@lwn.net>
    Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
    Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Cc: Liam R. Howlett <Liam.Howlett@oracle.com>
    Cc: Mike Kravetz <mike.kravetz@oracle.com>
    Cc: Mike Rapoport (IBM) <rppt@kernel.org>
    Cc: Muchun Song <muchun.song@linux.dev>
    Cc: "Rafael J. Wysocki" <rafael@kernel.org>
    Cc: Randy Dunlap <rdunlap@infradead.org>
    Cc: Shakeel Butt <shakeelb@google.com>
    Cc: Suren Baghdasaryan <surenb@google.com>
    Cc: Tomas Mudrunka <tomas.mudrunka@gmail.com>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Wei Xu <weixugc@google.com>
    Cc: Yang Yang <yang.yang29@zte.com.cn>
    Cc: Yosry Ahmed <yosryahmed@google.com>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    15995a35
sparse-vmemmap.c 12.1 KB