From: "zhen.ni" <zhen.ni@easystack.cn>
To: SeongJae Park <sj@kernel.org>
Cc: akpm@linux-foundation.org, vbabka@kernel.org, surenb@google.com,
mhocko@suse.com, jackmanb@google.com, hannes@cmpxchg.org,
ziy@nvidia.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 1/3] mm/page_owner: add print_mode filter
Date: Sat, 9 May 2026 14:54:58 +0800 [thread overview]
Message-ID: <c757f87f-2f2d-4200-99fb-75fff3dc891e@easystack.cn> (raw)
In-Reply-To: <20260509002902.83937-1-sj@kernel.org>
在 2026/5/9 08:29, SeongJae Park 写道:
> On Thu, 7 May 2026 14:46:41 +0800 Zhen Ni <zhen.ni@easystack.cn> wrote:
>
>> Add a print_mode filter to page_owner that allows users to choose between
>> printing full stack traces or only stack handles, significantly reducing
>> output size for debugging and analysis.
>>
>> The filter provides a string-based interface under
>> /sys/kernel/debug/page_owner_filter/:
>> - Reading shows the current mode with [] brackets around active option
>> - Writing accepts "full_stack" or "stack_handle" strings
>>
>> The default full_stack mode maintains backward compatibility with existing
>> usage, displaying complete stack traces for each page allocation.
>>
>> The stack_handle mode dramatically reduces log size by showing only
>> the handle number instead of the full stack trace. The mapping from
>> handles to actual stack traces can be obtained via the
>> show_stacks_handles interface.
>>
>> Example usage:
>> # echo stack_handle > /sys/kernel/debug/page_owner_filter/print_mode
>> # cat /sys/kernel/debug/page_owner_filter/print_mode
>> full_stack [stack_handle]
>> # cat /sys/kernel/debug/page_owner
>> 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
>> ...
>>
>> Signed-off-by: Zhen Ni <zhen.ni@easystack.cn>
>
> I added a few trivial comments below, but overall looks good to me.
>
> Reviewed-by: SeongJae Park <sj@kernel.org>
>
>> ---
>>
>> Changes in v5:
>> - No code changes
>>
>> Changes in v4:
>> - Change from numeric (0/1) to string-based interface ("full_stack"/"stack_handle")
>> - Merge infrastructure patch into this patch
>>
>> Changes in v3:
>> - No code changes
>>
>> Changes in v2:
>> - Renamed from 'compact mode' to 'print_mode' for better clarity
>> - Use enum values (0=full_stack, 1=stack_handle) instead of boolean
>> - Update debugfs filename from 'compact' to 'print_mode'
>
> Adding links to previous revisions would be helpful.
Good point. I will add lore links to all previous revisions in v6.
>
>> ---
>> mm/page_owner.c | 93 +++++++++++++++++++++++++++++++++++++++++++++++--
>> 1 file changed, 91 insertions(+), 2 deletions(-)
>>
>> diff --git a/mm/page_owner.c b/mm/page_owner.c
>> index 8178e0be557f..28766c854d02 100644
>> --- a/mm/page_owner.c
>> +++ b/mm/page_owner.c
> [...]
>> @@ -575,7 +594,11 @@ print_page_owner(char __user *buf, size_t count, unsigned long pfn,
>> migratetype_names[pageblock_mt],
>> &page->flags);
>>
>> - ret += stack_depot_snprint(handle, kbuf + ret, count - ret, 0);
>> + if (READ_ONCE(owner_filter.print_mode) == PAGE_OWNER_PRINT_STACK_HANDLE) {
>> + ret += scnprintf(kbuf + ret, count - ret,
>> + "handle: %d\n", handle);
>> + } else
>> + ret += stack_depot_snprint(handle, kbuf + ret, count - ret, 0);
>
> Braces are unnecessary [2] because both branches have only one statement.
>
Will fix in v6.
> [...]
>> +static ssize_t print_mode_write(struct file *file,
>> + const char __user *buf,
>> + size_t count, loff_t *ppos)
>> +{
>> + char *kbuf;
>> + int mode;
>> + int ret = count;
>> +
>> + /*
>> + * Limit input size. Maximum valid input is "stack_handle" (12 chars)
>> + * plus newline and null terminator. Use 32 bytes as a reasonable limit.
>> + */
>> + if (count > 32)
>> + return -EINVAL;
>> +
>> + kbuf = kmalloc(count + 1, GFP_KERNEL);
>> + if (!kbuf)
>> + return -ENOMEM;
>
> Would it make sense to use kmalloc_objs(), or simply using a local array as
> Andrew suggested?
I'll use a local array instead. Since the input is limited to 32 bytes,
a stack-allocated array should be sufficient and simpler:
char kbuf[32 + 1];
Thanks for the review!
>
> [...]
>
> [1] https://docs.kernel.org/process/submitting-patches.html#commentary
> [2] https://docs.kernel.org/process/coding-style.html#placing-braces-and-spaces
>
>
> Thanks,
> SJ
>
>
Best regards,
Zhen
next prev parent reply other threads:[~2026-05-09 6:55 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-07 6:46 [PATCH v5 0/3] mm/page_owner: add filter infrastructure for print_mode and NUMA filtering Zhen Ni
2026-05-07 6:46 ` [PATCH v5 1/3] mm/page_owner: add print_mode filter Zhen Ni
2026-05-08 21:13 ` Andrew Morton
2026-05-09 0:29 ` SeongJae Park
2026-05-09 6:54 ` zhen.ni [this message]
2026-05-07 6:46 ` [PATCH v5 2/3] mm/page_owner: add NUMA node filter with nodelist support Zhen Ni
2026-05-09 0:44 ` SeongJae Park
2026-05-09 7:27 ` zhen.ni
2026-05-09 15:35 ` SeongJae Park
2026-05-07 6:46 ` [PATCH v5 3/3] mm/page_owner: document page_owner filter features Zhen Ni
2026-05-09 0:51 ` SeongJae Park
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=c757f87f-2f2d-4200-99fb-75fff3dc891e@easystack.cn \
--to=zhen.ni@easystack.cn \
--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=sj@kernel.org \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.