[PATCH] mm/slab: Add slabreclaim flag to slabinfo

[PATCH] mm/slab: Add slabreclaim flag to slabinfo

[Fangzheng Zhang]

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@unisoc.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>");
 	seq_putc(m, '\n');
 }
 
@@ -1071,8 +1071,9 @@ static void cache_show(struct kmem_cache *s, struct seq_file *m)
 
 	seq_printf(m, " : tunables %4u %4u %4u",
 		   sinfo.limit, sinfo.batchcount, sinfo.shared);
-	seq_printf(m, " : slabdata %6lu %6lu %6lu",
-		   sinfo.active_slabs, sinfo.num_slabs, sinfo.shared_avail);
+	seq_printf(m, " : slabdata %6lu %6lu %6lu %6u",
+		   sinfo.active_slabs, sinfo.num_slabs, sinfo.shared_avail,
+		   !!(s->flags & SLAB_RECLAIM_ACCOUNT));
 	slabinfo_show_stats(m, s);
 	seq_putc(m, '\n');
 }
-- 
2.43.0

Re: [PATCH] mm/slab: Add slabreclaim flag to slabinfo

[Greg KH]

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@unisoc.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?

thanks,

greg k-h

Re: [PATCH] mm/slab: Add slabreclaim flag to slabinfo

[Vlastimil Babka]

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@unisoc.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?

Yeah I was vary about this. Do the other longer-time-than-me slab
maintainers recall how we handled this in the past?
Also the information is already available, even if harder to gather, in the
file /sys/kernel/slab/$cache/reclaim_account

> thanks,
> 
> greg k-h

Re: [PATCH] mm/slab: Add slabreclaim flag to slabinfo

[Christoph Lameter (Ampere)]

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@unisoc.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?

答复: [PATCH] mm/slab: Add slabreclaim flag to slabinfo

[张方正 (Fangzheng Zhang)]

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@linux.com> 
发送时间: 2024年2月6日 1:55
收件人: Vlastimil Babka <vbabka@suse.cz>
抄送: Greg KH <gregkh@linuxfoundation.org>; 张方正 (Fangzheng Zhang) <fangzheng.zhang@unisoc.com>; Pekka Enberg <penberg@kernel.org>; David Rientjes <rientjes@google.com>; Joonsoo Kim <iamjoonsoo.kim@lge.com>; Andrew Morton <akpm@linux-foundation.org>; Roman Gushchin <roman.gushchin@linux.dev>; Hyeonggon Yoo <42.hyeyoo@gmail.com>; linux-mm@kvack.org; linux-kernel@vger.kernel.org; Fangzheng Zhang <fangzheng.zhang1003@gmail.com>; 韩玉明 (Yuming Han) <yuming.han@unisoc.com>; Chunyan Zhang <zhang.lyra@gmail.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@unisoc.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?

Re: [PATCH] mm/slab: Add slabreclaim flag to slabinfo

[zhang fangzheng]

[-- Attachment #1: Type: text/plain, Size: 4523 bytes --]

On Tue, Feb 6, 2024 at 4:02 PM 张方正 (Fangzheng Zhang) <
fangzheng.zhang@unisoc.com> wrote:
>
> 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@linux.com>
> 发送时间: 2024年2月6日 1:55
> 收件人: Vlastimil Babka <vbabka@suse.cz>
> 抄送: Greg KH <gregkh@linuxfoundation.org>; 张方正 (Fangzheng Zhang) <
fangzheng.zhang@unisoc.com>; Pekka Enberg <penberg@kernel.org>; David
Rientjes <rientjes@google.com>; Joonsoo Kim <iamjoonsoo.kim@lge.com>;
Andrew Morton <akpm@linux-foundation.org>; Roman Gushchin <
roman.gushchin@linux.dev>; Hyeonggon Yoo <42.hyeyoo@gmail.com>;
linux-mm@kvack.org; linux-kernel@vger.kernel.org; Fangzheng Zhang <
fangzheng.zhang1003@gmail.com>; 韩玉明 (Yuming Han) <yuming.han@unisoc.com>;
Chunyan Zhang <zhang.lyra@gmail.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@unisoc.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 found that there is no corresponding slabinfo output example in the
Documentation/filesystems/proc.rst. Can we add an output example so that
user space knows about it?

> 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?
>
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 work we will consider marking /proc/slabinfo as deprecated, and then
use the "slabinfo" tool to implement the corresponding proc/slabinfo
function.

Thanks.

[-- Attachment #2: Type: text/html, Size: 6049 bytes --]

Re: [PATCH] mm/slab: Add slabreclaim flag to slabinfo

[zhang fangzheng]

On Mon, Feb 5, 2024 at 4:50 PM Vlastimil Babka <vbabka@suse.cz> 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@unisoc.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?
>
Ok, I will  modify the slabinfo version number to 2.2 and I find that
there is no corresponding slabinfo output example in the proc.rst
document. Can we add an output example so that user space knows about
it?

> Yeah I was vary about this. Do the other longer-time-than-me slab
> maintainers recall how we handled this in the past?
> Also the information is already available, even if harder to gather, in the
> file /sys/kernel/slab/$cache/reclaim_account
>
First  of all, thank you very much for your comments.

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 you 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.

> > thanks,
> >
> > greg k-h
>
Thanks.

[PATCH] mm/slab: Add slabreclaim flag to slabinfo

[Chunyan Zhang]

From: Fangzheng Zhang <fangzheng.zhang@unisoc.com>

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@unisoc.com>
Signed-off-by: Chunyan Zhang <chunyan.zhang@unisoc.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>");
        seq_putc(m, '\n');
 }

@@ -1071,8 +1071,9 @@ static void cache_show(struct kmem_cache *s, struct seq_file *m)

        seq_printf(m, " : tunables %4u %4u %4u",
                   sinfo.limit, sinfo.batchcount, sinfo.shared);
-       seq_printf(m, " : slabdata %6lu %6lu %6lu",
-                  sinfo.active_slabs, sinfo.num_slabs, sinfo.shared_avail);
+       seq_printf(m, " : slabdata %6lu %6lu %6lu %6u",
+                  sinfo.active_slabs, sinfo.num_slabs, sinfo.shared_avail,
+                  !!(s->flags & SLAB_RECLAIM_ACCOUNT));
        slabinfo_show_stats(m, s);
        seq_putc(m, '\n');
 }
--
2.43.0

________________________________
 This email (including its attachments) is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. Unauthorized use, dissemination, distribution or copying of this email or the information herein or taking any action in reliance on the contents of this email or the information herein, by anyone other than the intended recipient, or an employee or agent responsible for delivering the message to the intended recipient, is strictly prohibited. If you are not the intended recipient, please do not read, copy, use or disclose any part of this e-mail to others. Please notify the sender immediately and permanently delete this e-mail and any attachments if you received it in error. Internet communications cannot be guaranteed to be timely, secure, error-free or virus-free. The sender does not accept liability for any errors or omissions.
本邮件及其附件具有保密性质，受法律保护不得泄露，仅发送给本邮件所指特定收件人。严禁非经授权使用、宣传、发布或复制本邮件或其内容。若非该特定收件人，请勿阅读、复制、 使用或披露本邮件的任何内容。若误收本邮件，请从系统中永久性删除本邮件及所有附件，并以回复邮件的方式即刻告知发件人。无法保证互联网通信及时、安全、无误或防毒。发件人对任何错漏均不承担责任。