Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1305808 > unrolled thread

[PATCH] mm: add ratio in slabinfo print

Started byXishi Qiu <qiuxishi@huawei.com>
First post2016-01-11 05:00 +0100
Last post2016-01-12 02:10 +0100
Articles 6 — 3 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH] mm: add ratio in slabinfo print Xishi Qiu <qiuxishi@huawei.com> - 2016-01-11 05:00 +0100
    Re: [PATCH] mm: add ratio in slabinfo print Michal Hocko <mhocko@kernel.org> - 2016-01-11 13:30 +0100
      Re: [PATCH] mm: add ratio in slabinfo print Xishi Qiu <qiuxishi@huawei.com> - 2016-01-11 14:50 +0100
        Re: [PATCH] mm: add ratio in slabinfo print Michal Hocko <mhocko@kernel.org> - 2016-01-11 14:50 +0100
        Re: [PATCH] mm: add ratio in slabinfo print David Rientjes <rientjes@google.com> - 2016-01-12 01:30 +0100
          Re: [PATCH] mm: add ratio in slabinfo print Xishi Qiu <qiuxishi@huawei.com> - 2016-01-12 02:10 +0100

#1305808 — [PATCH] mm: add ratio in slabinfo print

FromXishi Qiu <qiuxishi@huawei.com>
Date2016-01-11 05:00 +0100
Subject[PATCH] mm: add ratio in slabinfo print
Message-ID<qPBOc-5gC-59@gated-at.bofh.it>
Add ratio(active_objs/num_objs) in /proc/slabinfo, it is used to show
the availability factor in each slab. Also adjustment format because
some slabs' name is too long.

before applied
...
ext4_inode_cache    1591   3008   1008   32    8 : tunables    0    0    0 : slabdata     94     94      0
ext4_free_data       640    640     64   64    1 : tunables    0    0    0 : slabdata     10     10      0
ext4_allocation_context    480    480    128   32    1 : tunables    0    0    0 : slabdata     15     15      0
ext4_io_end          616    616     72   56    1 : tunables    0    0    0 : slabdata     11     11      0
ext4_extent_status   3979   4794     40  102    1 : tunables    0    0    0 : slabdata     47     47      0
jbd2_journal_handle   1360   1360     48   85    1 : tunables    0    0    0 : slabdata     16     16      0
jbd2_journal_head    510    510    120   34    1 : tunables    0    0    0 : slabdata     15     15      0
jbd2_revoke_table_s    768    768     16  256    1 : tunables    0    0    0 : slabdata      3      3      0
jbd2_revoke_record_s    384    384     32  128    1 : tunables    0    0    0 : slabdata      3      3      0
scsi_data_buffer       0      0     24  170    1 : tunables    0    0    0 : slabdata      0      0      0
cfq_queue            560    560    232   35    2 : tunables    0    0    0 : slabdata     16     16      0
bsg_cmd                0      0    312   26    2 : tunables    0    0    0 : slabdata      0      0      0
mqueue_inode_cache     36     36    896   36    8 : tunables    0    0    0 : slabdata      1      1      0
isofs_inode_cache      0      0    600   27    4 : tunables    0    0    0 : slabdata      0      0      0
hugetlbfs_inode_cache     28     28    568   28    4 : tunables    0    0    0 : slabdata      1      1      0
dquot                448    448    256   32    2 : tunables    0    0    0 : slabdata     14     14      0

after applied
...
ext4_inode_cache            1287   2400     53%   1008   32    8 : tunables    0    0    0 : slabdata     75     75      0
ext4_free_data               640    640    100%     64   64    1 : tunables    0    0    0 : slabdata     10     10      0
ext4_allocation_context      512    512    100%    128   32    1 : tunables    0    0    0 : slabdata     16     16      0
ext4_io_end                  560    560    100%     72   56    1 : tunables    0    0    0 : slabdata     10     10      0
ext4_extent_status          3775   4692     80%     40  102    1 : tunables    0    0    0 : slabdata     46     46      0
jbd2_journal_handle         1360   1360    100%     48   85    1 : tunables    0    0    0 : slabdata     16     16      0
jbd2_journal_head            544    544    100%    120   34    1 : tunables    0    0    0 : slabdata     16     16      0
jbd2_revoke_table_s          768    768    100%     16  256    1 : tunables    0    0    0 : slabdata      3      3      0
jbd2_revoke_record_s         512    512    100%     32  128    1 : tunables    0    0    0 : slabdata      4      4      0
scsi_data_buffer               0      0      0%     24  170    1 : tunables    0    0    0 : slabdata      0      0      0
cfq_queue                    560    560    100%    232   35    2 : tunables    0    0    0 : slabdata     16     16      0
bsg_cmd                        0      0      0%    312   26    2 : tunables    0    0    0 : slabdata      0      0      0
mqueue_inode_cache            36     36    100%    896   36    8 : tunables    0    0    0 : slabdata      1      1      0
isofs_inode_cache              0      0      0%    600   27    4 : tunables    0    0    0 : slabdata      0      0      0
hugetlbfs_inode_cache         28     28    100%    568   28    4 : tunables    0    0    0 : slabdata      1      1      0
dquot                        448    448    100%    256   32    2 : tunables    0    0    0 : slabdata     14     14      0

Signed-off-by: Xishi Qiu <qiuxishi@huawei.com>
---
 mm/slab_common.c | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/mm/slab_common.c b/mm/slab_common.c
index 3c6a86b..6f1e130 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -1041,8 +1041,8 @@ static void print_slabinfo_header(struct seq_file *m)
 #else
 	seq_puts(m, "slabinfo - version: 2.1\n");
 #endif
-	seq_puts(m, "# name            <active_objs> <num_objs> <objsize> "
-		 "<objperslab> <pagesperslab>");
+	seq_puts(m, "# name                   <active_objs> <num_objs> <ratio> "
+		 "<objsize> <objperslab> <pagesperslab>");
 	seq_puts(m, " : tunables <limit> <batchcount> <sharedfactor>");
 	seq_puts(m, " : slabdata <active_slabs> <num_slabs> <sharedavail>");
 #ifdef CONFIG_DEBUG_SLAB
@@ -1093,15 +1093,18 @@ memcg_accumulate_slabinfo(struct kmem_cache *s, struct slabinfo *info)
 static void cache_show(struct kmem_cache *s, struct seq_file *m)
 {
 	struct slabinfo sinfo;
+	unsigned long ratio;
 
 	memset(&sinfo, 0, sizeof(sinfo));
 	get_slabinfo(s, &sinfo);
 
 	memcg_accumulate_slabinfo(s, &sinfo);
+	ratio = sinfo.num_objs ? sinfo.active_objs * 100 / sinfo.num_objs : 0;
 
-	seq_printf(m, "%-17s %6lu %6lu %6u %4u %4d",
-		   cache_name(s), sinfo.active_objs, sinfo.num_objs, s->size,
-		   sinfo.objects_per_slab, (1 << sinfo.cache_order));
+	seq_printf(m, "%-25s %6lu %6lu %6lu%% %6u %4u %4d",
+		   cache_name(s), sinfo.active_objs, sinfo.num_objs,
+		   ratio, s->size, sinfo.objects_per_slab,
+		   (1 << sinfo.cache_order));
 
 	seq_printf(m, " : tunables %4u %4u %4u",
 		   sinfo.limit, sinfo.batchcount, sinfo.shared);
-- 
2.0.0

[toc] | [next] | [standalone]


#1306146

FromMichal Hocko <mhocko@kernel.org>
Date2016-01-11 13:30 +0100
Message-ID<qPJLJ-2jg-45@gated-at.bofh.it>
In reply to#1305808
On Mon 11-01-16 11:54:57, Xishi Qiu wrote:
> Add ratio(active_objs/num_objs) in /proc/slabinfo, it is used to show
> the availability factor in each slab.

What is the reason to add such a new value when it can be trivially
calculated from the userspace?

Besides that such a change would break existing parsers no?
-- 
Michal Hocko
SUSE Labs

[toc] | [prev] | [next] | [standalone]


#1306218

FromXishi Qiu <qiuxishi@huawei.com>
Date2016-01-11 14:50 +0100
Message-ID<qPL18-34y-17@gated-at.bofh.it>
In reply to#1306146
On 2016/1/11 20:25, Michal Hocko wrote:

> On Mon 11-01-16 11:54:57, Xishi Qiu wrote:
>> Add ratio(active_objs/num_objs) in /proc/slabinfo, it is used to show
>> the availability factor in each slab.
> 
> What is the reason to add such a new value when it can be trivially
> calculated from the userspace?
> 
> Besides that such a change would break existing parsers no?

Oh, maybe it is.

How about adjustment the format because some names are too long?

Thanks,
Xishi Qiu

[toc] | [prev] | [next] | [standalone]


#1306222

FromMichal Hocko <mhocko@kernel.org>
Date2016-01-11 14:50 +0100
Message-ID<qPL18-34y-21@gated-at.bofh.it>
In reply to#1306218
On Mon 11-01-16 21:15:01, Xishi Qiu wrote:
> On 2016/1/11 20:25, Michal Hocko wrote:
> 
> > On Mon 11-01-16 11:54:57, Xishi Qiu wrote:
> >> Add ratio(active_objs/num_objs) in /proc/slabinfo, it is used to show
> >> the availability factor in each slab.
> > 
> > What is the reason to add such a new value when it can be trivially
> > calculated from the userspace?
> > 
> > Besides that such a change would break existing parsers no?
> 
> Oh, maybe it is.
> 
> How about adjustment the format because some names are too long?

Parsers should be clever enough to process white spaces properly but
there is no guarantee this will be the case. A more important question
is whether it really makes sense to change this in the first place. What
would be the benefit? Somehow nicer output? Does this justify a potential
breakage of tool processing this file? To me this all sounds like such a
change is not worth it.
-- 
Michal Hocko
SUSE Labs

[toc] | [prev] | [next] | [standalone]


#1306856

FromDavid Rientjes <rientjes@google.com>
Date2016-01-12 01:30 +0100
Message-ID<qPV0u-1AF-21@gated-at.bofh.it>
In reply to#1306218
On Mon, 11 Jan 2016, Xishi Qiu wrote:

> > On Mon 11-01-16 11:54:57, Xishi Qiu wrote:
> >> Add ratio(active_objs/num_objs) in /proc/slabinfo, it is used to show
> >> the availability factor in each slab.
> > 
> > What is the reason to add such a new value when it can be trivially
> > calculated from the userspace?
> > 
> > Besides that such a change would break existing parsers no?
> 
> Oh, maybe it is.
> 

If you need the information internally, you could always create a library 
around slabinfo and export the information for users who are interested 
for your own use.  Doing anything other than appending fields to each line 
is too dangerous, however, as a general rule.

[toc] | [prev] | [next] | [standalone]


#1306880

FromXishi Qiu <qiuxishi@huawei.com>
Date2016-01-12 02:10 +0100
Message-ID<qPVDc-25w-5@gated-at.bofh.it>
In reply to#1306856
On 2016/1/12 8:20, David Rientjes wrote:

> On Mon, 11 Jan 2016, Xishi Qiu wrote:
> 
>>> On Mon 11-01-16 11:54:57, Xishi Qiu wrote:
>>>> Add ratio(active_objs/num_objs) in /proc/slabinfo, it is used to show
>>>> the availability factor in each slab.
>>>
>>> What is the reason to add such a new value when it can be trivially
>>> calculated from the userspace?
>>>
>>> Besides that such a change would break existing parsers no?
>>
>> Oh, maybe it is.
>>
> 
> If you need the information internally, you could always create a library 
> around slabinfo and export the information for users who are interested 
> for your own use.  Doing anything other than appending fields to each line 
> is too dangerous, however, as a general rule.
> 
> 

OK, I know.

Thanks,
Xishi Qiu

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web