This patch set 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()
Revision History
=================
Changes from v1 [1]
- Dump status of memory allocation profiling instead of disabling
the output following Vishal's advise.
- Move lock from file scope to within __show_mem() and replace mutex
with spinlock following Andrew, Vlastimil and Shakeel's advice.
[1] https://lore.kernel.org/linux-mm/cover.1756318426.git.pyyjason@gmail.com/
Yueyang Pan (2):
mm/show_mem: Dump the status of the mem alloc profiling before
printing
mm/show_mem: Add trylock while printing alloc info
mm/show_mem.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--
2.47.3