Re: [PATCH v3 00/35] Memory allocation profiling
From: Kent Overstreet <kent.overstreet@linux.dev>
Date: 2024-02-16 08:42:48
Also in:
cgroups, linux-arch, linux-doc, linux-fsdevel, linux-iommu, linux-mm, lkml
Subsystem:
documentation, memory allocation profiling, memory management - misc, the rest · Maintainers:
Jonathan Corbet, Suren Baghdasaryan, Kent Overstreet, Andrew Morton, David Hildenbrand, Linus Torvalds
On Fri, Feb 16, 2024 at 10:38:00AM +0200, Jani Nikula wrote:
On Mon, 12 Feb 2024, Suren Baghdasaryan [off-list ref] wrote:quoted
Memory allocation, v3 and final: Overview: Low overhead [1] per-callsite memory allocation profiling. Not just for debug kernels, overhead low enough to be deployed in production. We're aiming to get this in the next merge window, for 6.9. The feedback we've gotten has been that even out of tree this patchset has already been useful, and there's a significant amount of other work gated on the code tagging functionality included in this patchset [2].I wonder if it wouldn't be too much trouble to write at least a brief overview document under Documentation/ describing what this is all about? Even as follow-up. People seeing the patch series have the benefit of the cover letter and the commit messages, but that's hardly documentation. We have all these great frameworks and tools but their discoverability to kernel developers isn't always all that great.
commit f589b48789de4b8f77bfc70b9f3ab2013c01eaf2
Author: Kent Overstreet [off-list ref]
Date: Wed Feb 14 01:13:04 2024 -0500
memprofiling: Documentation
Signed-off-by: Kent Overstreet [off-list ref]
diff --git a/Documentation/mm/allocation-profiling.rst b/Documentation/mm/allocation-profiling.rst
new file mode 100644
index 000000000000..d906e9360279
--- /dev/null
+++ b/Documentation/mm/allocation-profiling.rst@@ -0,0 +1,68 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=========================== +MEMORY ALLOCATION PROFILING +=========================== + +Low overhead (suitable for production) accounting of all memory allocations, +tracked by file and line number. + +Usage: +kconfig options: + - CONFIG_MEM_ALLOC_PROFILING + - CONFIG_MEM_ALLOC_PROFILING_ENABLED_BY_DEFAULT + - CONFIG_MEM_ALLOC_PROFILING_DEBUG + adds warnings for allocations that weren't accounted because of a + missing annotation + +sysctl: + /proc/sys/vm/mem_profiling + +Runtime info: + /proc/allocinfo + +Example output: + root@moria-kvm:~# sort -h /proc/allocinfo|tail + 3.11MiB 2850 fs/ext4/super.c:1408 module:ext4 func:ext4_alloc_inode + 3.52MiB 225 kernel/fork.c:356 module:fork func:alloc_thread_stack_node + 3.75MiB 960 mm/page_ext.c:270 module:page_ext func:alloc_page_ext + 4.00MiB 2 mm/khugepaged.c:893 module:khugepaged func:hpage_collapse_alloc_folio + 10.5MiB 168 block/blk-mq.c:3421 module:blk_mq func:blk_mq_alloc_rqs + 14.0MiB 3594 include/linux/gfp.h:295 module:filemap func:folio_alloc_noprof + 26.8MiB 6856 include/linux/gfp.h:295 module:memory func:folio_alloc_noprof + 64.5MiB 98315 fs/xfs/xfs_rmap_item.c:147 module:xfs func:xfs_rui_init + 98.7MiB 25264 include/linux/gfp.h:295 module:readahead func:folio_alloc_noprof + 125MiB 7357 mm/slub.c:2201 module:slub func:alloc_slab_page + + +Theory of operation: + +Memory allocation profiling builds off of code tagging, which is a library for +declaring static structs (that typcially describe a file and line number in +some way, hence code tagging) and then finding and operating on them at runtime +- i.e. iterating over them to print them in debugfs/procfs. + +To add accounting for an allocation call, we replace it with a macro +invocation, alloc_hooks(), that + - declares a code tag + - stashes a pointer to it in task_struct + - calls the real allocation function + - and finally, restores the task_struct alloc tag pointer to its previous value. + +This allows for alloc_hooks() calls to be nested, with the most recent one +taking effect. This is important for allocations internal to the mm/ code that +do not properly belong to the outer allocation context and should be counted +separately: for example, slab object extension vectors, or when the slab +allocates pages from the page allocator. + +Thus, proper usage requires determining which function in an allocation call +stack should be tagged. There are many helper functions that essentially wrap +e.g. kmalloc() and do a little more work, then are called in multiple places; +we'll generally want the accounting to happen in the callers of these helpers, +not in the helpers themselves. + +To fix up a given helper, for example foo(), do the following: + - switch its allocation call to the _noprof() version, e.g. kmalloc_noprof() + - rename it to foo_noprof() + - define a macro version of foo() like so: + #define foo(...) alloc_hooks(foo_noprof(__VA_ARGS__))