From: Vlastimil Babka <vbabka@suse.cz>
To: Vasily Averin <vvs@virtuozzo.com>, Linux MM <linux-mm@kvack.org>,
Andrew Morton <akpm@linux-foundation.org>,
Christoph Lameter <cl@linux.com>,
David Rientjes <rientjes@google.com>,
Pekka Enberg <penberg@kernel.org>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Roman Gushchin <roman.gushchin@linux.dev>
Cc: kernel@openvz.org
Subject: Re: slabinfo shows incorrect active_objs ???
Date: Tue, 22 Feb 2022 12:10:53 +0100 [thread overview]
Message-ID: <b99b862a-761c-9d9f-3576-f52c2dd2c8be@suse.cz> (raw)
In-Reply-To: <a63adce4-190b-21ed-c62b-b2021b2de367@virtuozzo.com>
On 2/22/22 10:22, Vasily Averin wrote:
> Dear all,
>
> I've found that /proc/slabinfo shows inadequate numbers of in-use slab objects.
> it assumes that all objects stored in cpu caches are always 100% in use.
>
> for example:
> slabinfo shows that all 20 objects are in use.
>
> [root@fc34-vvs linux]# uname -a
> Linux fc34-vvs.sw.ru 5.17.0-rc3+ #42 SMP PREEMPT Mon Feb 21 20:14:54 UTC
> 2022 x86_64 x86_64 x86_64 GNU/Linux
>
> [root@fc34-vvs linux]# cat /proc/slabinfo
> slabinfo - version: 2.1
> # name <active_objs> <num_objs> <objsize> <objperslab>
> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata
> <active_slabs> <num_slabs> <sharedavail>
> ...
> kmalloc-cg-8k 20 20 8192 4 8 : tunables 0 0 0 :
> slabdata 5 5 0
>
> At the same time crash said that only 2 objects are in use.
>
> crash> kmem -s kmalloc-cg-8k
> CACHE OBJSIZE ALLOCATED TOTAL SLABS SSIZE NAME
> ffff8f4840043b00 8192 2 20 5 32k kmalloc-cg-8k
>
> And this looks like true, see kmem -S output below.
>
> Is it a bug or perhaps a well-known feature that I missed?
It's a known tradeoff. It would affect the allocation/free hot paths to
account the per-cpu slabs more accurately and thus some precision of
slabinfo is sacrificed.
> Numbers are counted in mm/slub.c, see below,
> but count_partial() doe not includes free objects of cpu caches
>
> Moreover adequate statistic is not showed in any other interfaces too
> /sys/kerenl/slab/ read cpu slab caches but does not output these numbers.
>
> Thank you,
> Vasily Averin
>
> #ifdef CONFIG_SLUB_DEBUG
> void get_slabinfo(struct kmem_cache *s, struct slabinfo *sinfo)
> {
> unsigned long nr_slabs = 0;
> unsigned long nr_objs = 0;
> unsigned long nr_free = 0;
> int node;
> struct kmem_cache_node *n;
>
> for_each_kmem_cache_node(s, node, n) {
> nr_slabs += node_nr_slabs(n);
> nr_objs += node_nr_objs(n);
> nr_free += count_partial(n, count_free);
> }
>
> sinfo->active_objs = nr_objs - nr_free;
> sinfo->num_objs = nr_objs;
>
>
>
> crash> kmem -S kmalloc-cg-8k
> CACHE OBJSIZE ALLOCATED TOTAL SLABS SSIZE NAME
> ffff8f4840043b00 8192 2 20 5 32k kmalloc-cg-8k
> CPU 0 KMEM_CACHE_CPU:
> ffff8f4b58236360
> CPU 0 SLAB:
> (empty)
> CPU 0 PARTIAL:
> (empty)
> CPU 1 KMEM_CACHE_CPU:
> ffff8f4b58276360
> CPU 1 SLAB:
> SLAB MEMORY NODE TOTAL ALLOCATED FREE
> ffffed3f842af400 ffff8f484abd0000 0 4 1 3
> FREE / [ALLOCATED]
> ffff8f484abd0000 (cpu 1 cache)
> ffff8f484abd2000 (cpu 1 cache)
> ffff8f484abd4000 (cpu 1 cache)
> [ffff8f484abd6000]
> CPU 1 PARTIAL:
> (empty)
> CPU 2 KMEM_CACHE_CPU:
> ffff8f4b582b6360
> CPU 2 SLAB:
> (empty)
> CPU 2 PARTIAL:
> (empty)
> CPU 3 KMEM_CACHE_CPU:
> ffff8f4b582f6360
> CPU 3 SLAB:
> SLAB MEMORY NODE TOTAL ALLOCATED FREE
> ffffed3f842ce600 ffff8f484b398000 0 4 0 4
> FREE / [ALLOCATED]
> ffff8f484b398000 (cpu 3 cache)
> ffff8f484b39a000 (cpu 3 cache)
> ffff8f484b39c000 (cpu 3 cache)
> ffff8f484b39e000 (cpu 3 cache)
> CPU 3 PARTIAL:
> (empty)
> CPU 4 KMEM_CACHE_CPU:
> ffff8f4b58336360
> CPU 4 SLAB:
> SLAB MEMORY NODE TOTAL ALLOCATED FREE
> ffffed3f8418c200 ffff8f4846308000 0 4 0 4
> FREE / [ALLOCATED]
> ffff8f4846308000 (cpu 4 cache)
> ffff8f484630a000 (cpu 4 cache)
> ffff8f484630c000 (cpu 4 cache)
> ffff8f484630e000 (cpu 4 cache)
> CPU 4 PARTIAL:
> (empty)
> CPU 5 KMEM_CACHE_CPU:
> ffff8f4b58376360
> CPU 5 SLAB:
> (empty)
> CPU 5 PARTIAL:
> (empty)
> CPU 6 KMEM_CACHE_CPU:
> ffff8f4b583b6360
> CPU 6 SLAB:
> SLAB MEMORY NODE TOTAL ALLOCATED FREE
> ffffed3f8412d000 ffff8f4844b40000 0 4 0 4
> FREE / [ALLOCATED]
> ffff8f4844b40000 (cpu 6 cache)
> ffff8f4844b42000 (cpu 6 cache)
> ffff8f4844b44000 (cpu 6 cache)
> ffff8f4844b46000 (cpu 6 cache)
> CPU 6 PARTIAL:
> (empty)
> CPU 7 KMEM_CACHE_CPU:
> ffff8f4b583f6360
> CPU 7 SLAB:
> SLAB MEMORY NODE TOTAL ALLOCATED FREE
> ffffed3f84124000 ffff8f4844900000 0 4 1 3
> FREE / [ALLOCATED]
> ffff8f4844900000 (cpu 7 cache)
> ffff8f4844902000 (cpu 7 cache)
> [ffff8f4844904000]
> ffff8f4844906000 (cpu 7 cache)
> CPU 7 PARTIAL:
> (empty)
> KMEM_CACHE_NODE NODE SLABS PARTIAL PER-CPU
> ffff8f48400416c0 0 5 0 5
> NODE 0 PARTIAL:
> (empty)
> NODE 0 FULL:
> (not tracked)
>
>
>
prev parent reply other threads:[~2022-02-22 11:10 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-22 9:22 Vasily Averin
2022-02-22 10:23 ` Hyeonggon Yoo
2022-02-22 12:10 ` Vasily Averin
2022-02-22 16:32 ` Shakeel Butt
2022-02-22 16:47 ` Roman Gushchin
2022-02-23 1:07 ` Vasily Averin
2022-02-22 20:59 ` Roman Gushchin
2022-02-22 23:08 ` Vlastimil Babka
2022-02-23 0:07 ` Roman Gushchin
2022-02-23 0:32 ` Vlastimil Babka
2022-02-23 3:45 ` Hyeonggon Yoo
2022-02-23 17:31 ` Vlastimil Babka
2022-02-23 18:15 ` Roman Gushchin
2022-02-24 13:16 ` Vasily Averin
2022-02-25 0:08 ` Roman Gushchin
2022-02-25 4:37 ` Vasily Averin
2022-02-28 6:17 ` Vasily Averin
2022-02-28 10:22 ` Hyeonggon Yoo
2022-02-28 10:28 ` Hyeonggon Yoo
2022-02-28 10:43 ` Hyeonggon Yoo
2022-02-28 12:09 ` Hyeonggon Yoo
2022-03-03 8:39 ` Christoph Lameter
2022-03-04 16:29 ` Vlastimil Babka
2022-02-22 11:10 ` Vlastimil Babka [this message]
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=b99b862a-761c-9d9f-3576-f52c2dd2c8be@suse.cz \
--to=vbabka@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=kernel@openvz.org \
--cc=linux-mm@kvack.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=vvs@virtuozzo.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox