summaryrefslogtreecommitdiff
path: root/rust/helpers
diff options
context:
space:
mode:
authorYueyang Pan <pyyjason@gmail.com>2025-09-03 04:16:13 -0700
committerAndrew Morton <akpm@linux-foundation.org>2025-09-21 14:22:18 -0700
commit9abd8bd4c6b16d152b7149ef2f27a606ae4ebf4e (patch)
treeacb84a4a57633ecb2b86549c58dcf4b311093dff /rust/helpers
parentd75d36547d11aed7fc0502e14f243873fb9c5844 (diff)
mm/show_mem: dump the status of the mem alloc profiling before printing
This patchset fixes two issues we saw in production rollout. The first issue is that we saw all zero output of memory allocation profiling information from show_mem() if CONFIG_MEM_ALLOC_PROFILING is set and sysctl.vm.mem_profiling=0. This cause ambiguity as we don't know what 0B actually means in the output. It can mean either memory allocation profiling is temporary disabled or the allocation at that position is actually 0. Such ambiguity will make further parsing harder as we cannot differentiate between two case. The second issue is that multiple entities can call show_mem() which messed up the allocation info in dmesg. We saw outputs like this: 327 MiB 83635 mm/compaction.c:1880 func:compaction_alloc 48.4 GiB 12684937 mm/memory.c:1061 func:folio_prealloc 7.48 GiB 10899 mm/huge_memory.c:1159 func:vma_alloc_anon_folio_pmd 298 MiB 95216 kernel/fork.c:318 func:alloc_thread_stack_node 250 MiB 63901 mm/zsmalloc.c:987 func:alloc_zspage 1.42 GiB 372527 mm/memory.c:1063 func:folio_prealloc 1.17 GiB 95693 mm/slub.c:2424 func:alloc_slab_page 651 MiB 166732 mm/readahead.c:270 func:page_cache_ra_unbounded 419 MiB 107261 net/core/page_pool.c:572 func:__page_pool_alloc_pages_slow 404 MiB 103425 arch/x86/mm/pgtable.c:25 func:pte_alloc_one The above example is because one kthread invokes show_mem() from __alloc_pages_slowpath while kernel itself calls oom_kill_process() This patch (of 2): This patch prints the status of the memory allocation profiling before __show_mem actually prints the detailed allocation info. This way will let us know the `0B` we saw in allocation info is because the profiling is disabled or the allocation is actually 0B. Link: https://lkml.kernel.org/r/cover.1756897825.git.pyyjason@gmail.com Link: https://lkml.kernel.org/r/d7998ea0ddc2ea1a78bb6e89adf530526f76679a.1756897825.git.pyyjason@gmail.com Signed-off-by: Yueyang Pan <pyyjason@gmail.com> Acked-by: Usama Arif <usamaarif642@gmail.com> Acked-by: Vlastimil Babka <vbabka@suse.cz> Acked-by: Zi Yan <ziy@nvidia.com> Acked-by: Suren Baghdasaryan <surenb@google.com> Reviewed-by: Vishal Moola (Oracle) <vishal.moola@gmail.com> Acked-by: Shakeel Butt <shakeel.butt@linux.dev> Cc: Brendan Jackman <jackmanb@google.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Michal Hocko <mhocko@suse.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Diffstat (limited to 'rust/helpers')
0 files changed, 0 insertions, 0 deletions