[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMZfGtX1pste5vY_RE3N5LQ1_+BUjyRbSUa1yf0v7vboJj_iOg@mail.gmail.com>
Date: Sun, 22 May 2022 14:47:42 +0800
From: Muchun Song <songmuchun@...edance.com>
To: Vasily Averin <vvs@...nvz.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>, kernel@...nvz.org,
LKML <linux-kernel@...r.kernel.org>,
Linux Memory Management List <linux-mm@...ck.org>,
Shakeel Butt <shakeelb@...gle.com>,
Roman Gushchin <roman.gushchin@...ux.dev>,
Michal Koutný <mkoutny@...e.com>,
Vlastimil Babka <vbabka@...e.cz>,
Michal Hocko <mhocko@...e.com>,
Cgroups <cgroups@...r.kernel.org>
Subject: Re: [PATCH mm v2 7/9] memcg: enable accounting for large allocations
in mem_cgroup_css_alloc
On Sun, May 22, 2022 at 12:38 AM Vasily Averin <vvs@...nvz.org> wrote:
>
> Creation of each memory cgroup allocates few huge objects in
> mem_cgroup_css_alloc(). Its size exceeds the size of memory
> accounted in common part of cgroup creation:
>
> common part: ~11Kb + 318 bytes percpu
> memcg: ~17Kb + 4692 bytes percpu
>
> memory:
> ------
> Allocs Alloc $1*$2 Sum Allocation
> number size
> --------------------------------------------
> 1 + 8192 8192 8192 (mem_cgroup_css_alloc+0x4a) <NB
> 14 ~ 352 4928 13120 KERNFS
> 1 + 2048 2048 15168 (mem_cgroup_css_alloc+0xdd) <NB
> 1 1024 1024 16192 (alloc_shrinker_info+0x79)
> 1 584 584 16776 (radix_tree_node_alloc.constprop.0+0x89)
> 2 64 128 16904 (percpu_ref_init+0x6a)
> 1 64 64 16968 (mem_cgroup_css_online+0x32)
>
> 1 = 3684 3684 3684 call_site=mem_cgroup_css_alloc+0x9e
> 1 = 984 984 4668 call_site=mem_cgroup_css_alloc+0xfd
> 2 12 24 4692 call_site=percpu_ref_init+0x23
>
> '=' -- already accounted,
> '+' -- to be accounted,
> '~' -- partially accounted
>
> Accounting for this memory helps to avoid misuse inside memcg-limited
> contianers.
>
> Signed-off-by: Vasily Averin <vvs@...nvz.org>
Reviewed-by: Muchun Song <songmuchun@...edance.com>
Powered by blists - more mailing lists