From: Yueyang Pan <pyyjason@gmail.com>
To: Suren Baghdasaryan <surenb@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Vlastimil Babka <vbabka@suse.cz>, Michal Hocko <mhocko@suse.com>,
Brendan Jackman <jackmanb@google.com>,
Johannes Weiner <hannes@cmpxchg.org>, Zi Yan <ziy@nvidia.com>,
Vishal Moola <vishal.moola@gmail.com>,
Shakeel Butt <shakeel.butt@linux.dev>,
Usama Arif <usamaarif642@gmail.com>
Cc: linux-mm@kvack.org, kernel-team@meta.com, linux-kernel@vger.kernel.org
Subject: [PATCH v3 0/2] mm/show_mem: Bug fix for print mem alloc info
Date: Wed, 3 Sep 2025 04:16:12 -0700 [thread overview]
Message-ID: <cover.1756897825.git.pyyjason@gmail.com> (raw)
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 v2 [2]
- Merge status dump with "Memory allocations:" starting line
- Move the definition of spinlock within ifdef
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/
[2] https://lore.kernel.org/linux-mm/cover.1756827906.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 | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
--
2.47.3
next reply other threads:[~2025-09-03 11:16 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-03 11:16 Yueyang Pan [this message]
2025-09-03 11:16 ` [PATCH v3 1/2] mm/show_mem: Dump the status of the mem alloc profiling before printing Yueyang Pan
2025-09-03 15:49 ` Usama Arif
2025-09-03 16:10 ` Vlastimil Babka
2025-09-03 16:29 ` Zi Yan
2025-09-03 17:07 ` Suren Baghdasaryan
2025-09-03 19:07 ` Vishal Moola (Oracle)
2025-09-04 23:53 ` Shakeel Butt
2025-09-03 11:16 ` [PATCH v3 2/2] mm/show_mem: Add trylock while printing alloc info Yueyang Pan
2025-09-03 15:48 ` Usama Arif
2025-09-03 16:10 ` Vlastimil Babka
2025-09-03 16:30 ` Zi Yan
2025-09-03 17:08 ` Suren Baghdasaryan
2025-09-04 23:53 ` Shakeel Butt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cover.1756897825.git.pyyjason@gmail.com \
--to=pyyjason@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=jackmanb@google.com \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=shakeel.butt@linux.dev \
--cc=surenb@google.com \
--cc=usamaarif642@gmail.com \
--cc=vbabka@suse.cz \
--cc=vishal.moola@gmail.com \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox