From: Zi Yan <ziy@nvidia.com>
To: "Vlastimil Babka (SUSE)" <vbabka@kernel.org>
Cc: Zhen Ni <zhen.ni@easystack.cn>, <akpm@linux-foundation.org>,
<surenb@google.com>, <mhocko@suse.com>, <jackmanb@google.com>,
<hannes@cmpxchg.org>, <linux-mm@kvack.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v12 1/4] mm/page_owner: add print_mode filter
Date: Tue, 07 Jul 2026 12:02:32 -0400 [thread overview]
Message-ID: <6C99BC03-CF3F-4629-BA70-E5FCFF359B8E@nvidia.com> (raw)
In-Reply-To: <117481D7-EF95-4123-BAD9-F9D24D1C94F2@nvidia.com>
On 7 Jul 2026, at 11:31, Zi Yan wrote:
> On 7 Jul 2026, at 11:27, Vlastimil Babka (SUSE) wrote:
>
>> On 7/7/26 13:54, Zhen Ni wrote:
>>> Add a print_mode filter to page_owner that allows users to choose between
>>> printing stack traces, stack handles, or both, providing flexibility for
>>> different debugging and analysis scenarios.
>>>
>>> The filter provides three modes via page_owner:
>>> - Writing "mode=stack" prints stack traces for each page (default)
>>> - Writing "mode=handle" prints only the handle number
>>> - Writing "mode=stack_handle" prints both stack traces and handles
>>>
>>> The default stack mode maintains backward compatibility with existing
>>> usage, displaying complete stack traces for each page allocation.
>>>
>>> The handle mode dramatically reduces log size and improves performance by
>>> showing only the handle number instead of the full stack trace. Testing
>>> shows handle mode reduces output size by ~66% (84MB vs 244MB) and
>>> improves read performance by ~4.4x compared to full stack output. The
>>> mapping from handles to actual stack traces can be obtained via the
>>> show_stacks_handles interface.
>>>
>>> The stack_handle mode prints both stack traces and handles, making it
>>> easier to identify pages with the same allocation pattern by comparing
>>> handle numbers instead of comparing large stack traces.
>>>
>>> Example usage:
>>> # Using the page_owner_filter tool (recommended)
>>> ./page_owner_filter -m stack # Print only stack traces (default)
>>> ./page_owner_filter -m handle # Print only handles
>>> ./page_owner_filter -m stack_handle # Print both stack and handles
>>>
>>> Sample output (handle mode):
>>> Page allocated via order 0, migratetype Unmovable, gfp_mask 0x1100ca,
>>> pid 1, tgid 1 (systemd), ts 123456789 ns
>>> PFN 0x1000 type Unmovable Block 1 type Unmovable
>>> Flags 0x3fffe800000084(referenced|lru|active|private|node=0|zone=1)
>>> handle: 17432583
>>> ...
>>>
>>> This implementation uses per-file-descriptor filter state stored in
>>> file->private_data, allowing each opener to have independent filter
>>> configuration.
>>>
>>> Signed-off-by: Zhen Ni <zhen.ni@easystack.cn>
>>> Tested-by: Zi Yan <ziy@nvidia.com>
>>
>> I think in general Tested-by" can't carry from previous version due to
>> (functional) changes. Andrew can remove it locally, or Zi can re-test :)
>
> Let me do a quick retest. :)
>
Everything works as expected as I just tested the code using the supplied
userspace tool. I also discovered a small typo in Patch 2. ;)
1. I used the tool manual with NUMA filter + handle|stack|stack_handle.
2. I also used the script from the cover letter and checked the output.
Tested-by: Zi Yan <ziy@nvidia.com>
Best Regards,
Yan, Zi
next prev parent reply other threads:[~2026-07-07 16:02 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-07 11:54 [PATCH v12 0/4] mm/page_owner: add per-fd filter infrastructure for print_mode and NUMA filtering Zhen Ni
2026-07-07 11:54 ` [PATCH v12 1/4] mm/page_owner: add print_mode filter Zhen Ni
2026-07-07 15:27 ` Vlastimil Babka (SUSE)
2026-07-07 15:31 ` Zi Yan
2026-07-07 16:02 ` Zi Yan [this message]
2026-07-07 11:54 ` [PATCH v12 2/4] mm/page_owner: add NUMA node filter Zhen Ni
2026-07-07 15:30 ` Vlastimil Babka (SUSE)
2026-07-07 15:54 ` Zi Yan
2026-07-07 11:54 ` [PATCH v12 3/4] tools/mm: add page_owner_filter userspace tool Zhen Ni
2026-07-07 15:36 ` Vlastimil Babka (SUSE)
2026-07-07 16:13 ` Zi Yan
2026-07-07 11:54 ` [PATCH v12 4/4] mm/page_owner: document page_owner filter Zhen Ni
2026-07-07 15:37 ` Vlastimil Babka (SUSE)
2026-07-07 16:13 ` Zi Yan
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=6C99BC03-CF3F-4629-BA70-E5FCFF359B8E@nvidia.com \
--to=ziy@nvidia.com \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=jackmanb@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
--cc=zhen.ni@easystack.cn \
/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