linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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)
> 
> 
> 



      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