public inbox for linux-mm@kvack.org
 help / color / mirror / Atom feed
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



             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