lkml.org 
[lkml]   [2024]   [Feb]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    From
    SubjectRe: [PATCH v3 00/35] Memory allocation profiling
    On Fri, Feb 16, 2024 at 10:38:00AM +0200, Jani Nikula wrote:
    > On Mon, 12 Feb 2024, Suren Baghdasaryan <surenb@google.com> wrote:
    > > 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 <kent.overstreet@linux.dev>
    Date: Wed Feb 14 01:13:04 2024 -0500

    memprofiling: Documentation

    Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>

    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__))
    \
     
     \ /
      Last update: 2024-05-27 15:06    [W:2.831 / U:0.988 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site