[<prev] [next>] [day] [month] [year] [list]
Message-ID: <f6d4305ac88b440e801d24949aca357d@BJMBX02.spreadtrum.com>
Date: Tue, 6 Feb 2024 07:57:28 +0000
From: 张方正 (Fangzheng Zhang)
<fangzheng.zhang@...soc.com>
To: "Christoph Lameter (Ampere)" <cl@...ux.com>,
Vlastimil Babka
<vbabka@...e.cz>
CC: Greg KH <gregkh@...uxfoundation.org>, Pekka Enberg <penberg@...nel.org>,
David Rientjes <rientjes@...gle.com>,
Joonsoo Kim <iamjoonsoo.kim@....com>,
Andrew Morton <akpm@...ux-foundation.org>,
Roman Gushchin
<roman.gushchin@...ux.dev>,
Hyeonggon Yoo <42.hyeyoo@...il.com>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>,
Fangzheng Zhang
<fangzheng.zhang1003@...il.com>,
韩玉明 (Yuming Han)
<yuming.han@...soc.com>,
Chunyan Zhang <zhang.lyra@...il.com>
Subject: 答复: [PATCH] mm/slab: Add slabreclaim flag to slabinfo
Frist, thank you very much for your comments and I would like to say, when performing slab memory information maintenance, people often hope to see more detailed information through a simple slabinfo command. As Vlastimil mentioned the method, but it is very unintuitive to the status of the entire slab, so we add the slabreclaim column to slabinfo and directly output it using cmdline ' > cat proc/slabinfo'. And I think this approach will also be helpful for future work on memory statistics. And I found that there is no corresponding slabinfo output example in the proc.rst document. Can we add a output example so that userspace knows about it?
Due to insufficient understanding of the code framework used by the slabinfo tool, this patch was not considered. Of course, I think in the next we will consider marking /proc/slabinfo as deprecated, and then use the "slabinfo" tool to implement the corresponding proc/slabinfo functions.
Thanks again!
-----邮件原件-----
发件人: Christoph Lameter (Ampere) <cl@...ux.com>
发送时间: 2024年2月6日 1:55
收件人: Vlastimil Babka <vbabka@...e.cz>
抄送: Greg KH <gregkh@...uxfoundation.org>; 张方正 (Fangzheng Zhang) <fangzheng.zhang@...soc.com>; Pekka Enberg <penberg@...nel.org>; David Rientjes <rientjes@...gle.com>; Joonsoo Kim <iamjoonsoo.kim@....com>; Andrew Morton <akpm@...ux-foundation.org>; Roman Gushchin <roman.gushchin@...ux.dev>; Hyeonggon Yoo <42.hyeyoo@...il.com>; linux-mm@...ck.org; linux-kernel@...r.kernel.org; Fangzheng Zhang <fangzheng.zhang1003@...il.com>; 韩玉明 (Yuming Han) <yuming.han@...soc.com>; Chunyan Zhang <zhang.lyra@...il.com>
主题: Re: [PATCH] mm/slab: Add slabreclaim flag to slabinfo
注意: 这封邮件来自于外部。除非你确定邮件内容安全,否则不要点击任何链接和附件。
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
On Mon, 5 Feb 2024, Vlastimil Babka wrote:
> On 2/4/24 14:09, Greg KH wrote:
>> On Wed, Jan 31, 2024 at 05:44:42PM +0800, Fangzheng Zhang wrote:
>>> In order to enhance slab debugging, we add slabreclaim flag to
>>> slabinfo. Slab type is also an important analysis point in slabinfo
>>> for per slab, when various problems such as memory leaks or memory
>>> statistics occur.
>>>
>>> Signed-off-by: Fangzheng Zhang <fangzheng.zhang@...soc.com>
>>> ---
>>> mm/slab_common.c | 7 ++++---
>>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/mm/slab_common.c b/mm/slab_common.c index
>>> 238293b1dbe1..aeeb2bfe6dda 100644
>>> --- a/mm/slab_common.c
>>> +++ b/mm/slab_common.c
>>> @@ -1038,7 +1038,7 @@ static void print_slabinfo_header(struct seq_file *m)
>>> seq_puts(m, "slabinfo - version: 2.1\n");
>>> seq_puts(m, "# name <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab>");
>>> seq_puts(m, " : tunables <limit> <batchcount> <sharedfactor>");
>>> - seq_puts(m, " : slabdata <active_slabs> <num_slabs> <sharedavail>");
>>> + seq_puts(m, " : slabdata <active_slabs> <num_slabs>
>>> + <sharedavail> <slabreclaim>");
>>
>> Doesn't this change the slabinfo version number above? Where is this
>> change documented so that userspace knows about it?
I have never seen such a document. I would suggest incrementing the version to 2.2 since there is a minor extension of the format.
I tried to remove /proc/slabinfo in the past and have people use the more versatile /sys/kernel/slab interface. But /proc/slabinfo has a long legacy.
Could we mark /proc/slabinfo as deprecated and recommend the use of either sysfs directly or use of the "slabinfo" tool that we have been providing in linux/tools/mm for a long time?
Powered by blists - more mailing lists