From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-m19731104.qiye.163.com (mail-m19731104.qiye.163.com [220.197.31.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CDC753F54B9 for ; Wed, 29 Apr 2026 11:57:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=220.197.31.104 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777463860; cv=none; b=q0gEN9fXt7VLKa+RwH5PIo09XbBitmzbExgeXqQxK8Z6bNA9wB1L/heIrkOosyh+0nnPYm2o4+QGjSoa0WhYcDi6+GWx0J3ZyZhR5zwDSLF1F8Oa7KjtiQzhydZVy5ylNlWD7iXJtQoYQTcAJIIKiAal1YmAmKSuG2lVmSYFsN4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777463860; c=relaxed/simple; bh=NIvbA0V/Zq+w7JCEYkHpWEATDf3GyaGmKhtFLKTtYgY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=L5uSwU2lsT4wr1Gu1NxA3vois/ifvKBpm61kIsk9zeY1ALMiI+G/Q/fuaVNxFaEqCv7vcsF5pU4neVFFIHtlDKUdVkkqRxl/AUG2N4wQLLjfJt4ipcH0/0wjsvkJwfiOjTX2VZK7gJJIcVcGSWhVsxjiKxVVwo0LpF0cdKAbq2c= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=easystack.cn; spf=pass smtp.mailfrom=easystack.cn; arc=none smtp.client-ip=220.197.31.104 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=easystack.cn Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=easystack.cn Received: from [192.168.0.18] (unknown [218.94.118.90]) by smtp.qiye.163.com (Hmail) with ESMTP id 198bcccc8; Wed, 29 Apr 2026 19:42:05 +0800 (GMT+08:00) Message-ID: <38340de6-c729-4b04-a42b-36cbd6585c9c@easystack.cn> Date: Wed, 29 Apr 2026 19:42:04 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/3] mm/page_owner: add print_mode filter To: Zi Yan Cc: akpm@linux-foundation.org, vbabka@kernel.org, surenb@google.com, mhocko@suse.com, jackmanb@google.com, hannes@cmpxchg.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20260419155540.376847-1-zhen.ni@easystack.cn> <20260419155540.376847-3-zhen.ni@easystack.cn> <41EDDEC1-9BAB-447D-AAB0-B8B22289F19C@nvidia.com> <0f9e11c8-743e-45be-8fbc-ea81d7592ae3@easystack.cn> From: "zhen.ni" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-HM-Tid: 0a9dd90bd68c0229kunm5e0ad9c11bc427 X-HM-MType: 1 X-HM-Spam-Status: e1kfGhgUHx5ZQUpXWQgPGg8OCBgUHx5ZQUlOS1dZFg8aDwILHllBWSg2Ly tZV1koWUFJQjdXWRgWCB1ZQUpXWS1ZQUlXWQ8JGhUIEh9ZQVkaThpCVhlNSkkaTUoeGU0fSVYVFA kWGhdVGRETFhoSFyQUDg9ZV1kYEgtZQVlJSkNVQk9VSkpDVUJLWVdZFhoPEhUdFFlBWU9LSFVCQk lOS1VKS0tVSkJLQlkG 在 2026/4/28 21:20, Zi Yan 写道: > On 27 Apr 2026, at 23:36, zhen.ni wrote: > >> 在 2026/4/27 23:43, Zi Yan 写道: >>> On 19 Apr 2026, at 11:55, Zhen Ni wrote: >>> >>>> Add print_mode functionality to reduce page_owner output size by >>>> printing only the stack handle instead of the full stack trace. >>>> >>>> Example output with print_mode enabled: >>>> Page allocated via order 0, mask 0x42800(GFP_NOWAIT|__GFP_COMP), >>>> pid 1, tgid 1 (systemd), ts 349667370 ns >>>> PFN 0xa00a2 type Unmovable Block 1280 type Unmovable >>>> Flags 0x33fffe0000004124(referenced|lru|active|private|node=3|zone=0| >>>> lastcpupid=0x1ffff) >>>> handle: 17432583 >>>> Charged to memcg / >>>> >>>> Print mode significantly reduces output size while preserving all >>>> other page allocation information. The correspondence between handles >>>> and stack traces can be obtained through the show_stacks_handles interface. >>>> >>>> Link: https://lore.kernel.org/linux-mm/20260417154638.22370-3-zhen.ni@easystack.cn/ >>>> Suggested-by: Zi Yan >>>> Signed-off-by: Zhen Ni >>>> --- >>>> >>>> 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' >>>> --- >>>> mm/page_owner.c | 28 +++++++++++++++++++++++++++- >>>> 1 file changed, 27 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/mm/page_owner.c b/mm/page_owner.c >>>> index 5884d883837e..6d87b6948cfa 100644 >>>> --- a/mm/page_owner.c >>>> +++ b/mm/page_owner.c >>>> @@ -590,7 +590,13 @@ 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); >>>> + /* Print mode: full stack or stack handle */ >>>> + 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); >>>> + } >>>> if (ret >= count) >>>> goto err; >>>> >>>> @@ -985,6 +991,24 @@ static int page_owner_threshold_set(void *data, u64 val) >>>> DEFINE_SIMPLE_ATTRIBUTE(page_owner_threshold_fops, &page_owner_threshold_get, >>>> &page_owner_threshold_set, "%llu"); >>>> >>>> +static int page_owner_print_mode_get(void *data, u64 *val) >>>> +{ >>>> + *val = READ_ONCE(owner_filter.print_mode); >>>> + return 0; >>>> +} >>>> + >>>> +static int page_owner_print_mode_set(void *data, u64 val) >>>> +{ >>>> + if (val > PAGE_OWNER_PRINT_STACK_HANDLE) >>>> + return -EINVAL; >>>> + WRITE_ONCE(owner_filter.print_mode, val); >>>> + return 0; >>>> +} >>>> + >>>> +DEFINE_SIMPLE_ATTRIBUTE(page_owner_print_mode_fops, >>>> + &page_owner_print_mode_get, >>>> + &page_owner_print_mode_set, "%lld"); >>>> + >>>> >>>> static int __init pageowner_init(void) >>>> { >>>> @@ -998,6 +1022,8 @@ static int __init pageowner_init(void) >>>> debugfs_create_file("page_owner", 0400, NULL, NULL, &page_owner_fops); >>>> >>>> filter_dir = debugfs_create_dir("page_owner_filter", NULL); >>>> + debugfs_create_file("print_mode", 0600, filter_dir, NULL, >>>> + &page_owner_print_mode_fops); >>>> >>>> dir = debugfs_create_dir("page_owner_stacks", NULL); >>>> debugfs_create_file("show_stacks", 0400, dir, >>>> -- >>>> 2.20.1 >>> >>> I think it is more user-friendly to use “full_stack” and “stack_handle” >>> instead of 0 and 1. You can refer to [1] to sysfs_match_string() to >>> do that. I was testing the interface, but needed to look at your code >>> to know which print_mode I am using. ;) >>> >>> >>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/tree/mm/huge_memory.c?h=mm-everything#n380 >>> >>> >> >> Thanks for the suggestion! >> >> I considered using "full_stack" and "stack_handle" strings, but >> I think the numeric values (0/1) are more concise and easier to type >> for users. > > I disagree. It is hard for user to know what the current print mode > is and what available modes are. 0 or 1 is usually for boolean input. > > Something like: > [full_stack] stack_handle > full_stack [stack_handle] > > is much easier for user to read and use. > The string-based interface is more user-friendly I'll switch to using string values "full_stack" and "stack_handle" with sysfs_match_string() in v4, implementing the show function to display them with [] brackets around the current selection. >> >> The v3 documentation will clarify the meaning: >> - 0 (default): Print full stack traces >> - 1: Print only stack handles >> >> Do you think this is sufficient, or would you still prefer using >> string values instead? >> >> >>> Best Regards, >>> Yan, Zi >>> >>> >> Best regards, >> Zhen > > > Best Regards, > Yan, Zi > > Best regards, Zhen