From: Roman Gushchin <guro@fb.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
kernel-team@fb.com, Johannes Weiner <hannes@cmpxchg.org>,
Andy Lutomirski <luto@kernel.org>,
Konstantin Khlebnikov <koct9i@gmail.com>,
Tejun Heo <tj@kernel.org>, Shakeel Butt <shakeelb@google.com>
Subject: Re: [PATCH v2 1/3] mm: rework memcg kernel stack accounting
Date: Thu, 23 Aug 2018 09:23:50 -0700 [thread overview]
Message-ID: <20180823162347.GA22650@tower.DHCP.thefacebook.com> (raw)
In-Reply-To: <20180822141213.GO29735@dhcp22.suse.cz>
On Wed, Aug 22, 2018 at 04:12:13PM +0200, Michal Hocko wrote:
> On Tue 21-08-18 14:35:57, Roman Gushchin wrote:
> > If CONFIG_VMAP_STACK is set, kernel stacks are allocated
> > using __vmalloc_node_range() with __GFP_ACCOUNT. So kernel
> > stack pages are charged against corresponding memory cgroups
> > on allocation and uncharged on releasing them.
> >
> > The problem is that we do cache kernel stacks in small
> > per-cpu caches and do reuse them for new tasks, which can
> > belong to different memory cgroups.
> >
> > Each stack page still holds a reference to the original cgroup,
> > so the cgroup can't be released until the vmap area is released.
> >
> > To make this happen we need more than two subsequent exits
> > without forks in between on the current cpu, which makes it
> > very unlikely to happen. As a result, I saw a significant number
> > of dying cgroups (in theory, up to 2 * number_of_cpu +
> > number_of_tasks), which can't be released even by significant
> > memory pressure.
> >
> > As a cgroup structure can take a significant amount of memory
> > (first of all, per-cpu data like memcg statistics), it leads
> > to a noticeable waste of memory.
> >
> > Signed-off-by: Roman Gushchin <guro@fb.com>
> > Cc: Johannes Weiner <hannes@cmpxchg.org>
> > Cc: Michal Hocko <mhocko@kernel.org>
> > Cc: Andy Lutomirski <luto@kernel.org>
> > Cc: Konstantin Khlebnikov <koct9i@gmail.com>
> > Cc: Tejun Heo <tj@kernel.org>
> > Cc: Shakeel Butt <shakeelb@google.com>
>
> Looks good to me. Two nits below.
>
> I am not sure stable tree backport is really needed but it would be nice
> to put
> Fixes: ac496bf48d97 ("fork: Optimize task creation by caching two thread stacks per CPU if CONFIG_VMAP_STACK=y")
>
> Acked-by: Michal Hocko <mhocko@suse.com>
Will add, thanks!
>
> > @@ -248,9 +253,20 @@ static unsigned long *alloc_thread_stack_node(struct task_struct *tsk, int node)
> > static inline void free_thread_stack(struct task_struct *tsk)
> > {
> > #ifdef CONFIG_VMAP_STACK
> > - if (task_stack_vm_area(tsk)) {
> > + struct vm_struct *vm = task_stack_vm_area(tsk);
> > +
> > + if (vm) {
> > int i;
> >
> > + for (i = 0; i < THREAD_SIZE / PAGE_SIZE; i++) {
> > + mod_memcg_page_state(vm->pages[i],
> > + MEMCG_KERNEL_STACK_KB,
> > + -(int)(PAGE_SIZE / 1024));
> > +
> > + memcg_kmem_uncharge(vm->pages[i],
> > + compound_order(vm->pages[i]));
>
> when do we have order > 0 here?
I guess, it's not possible, but hard-coded 1 looked a bit crappy.
Do you think it's better?
> Also I was wondering how come this
> doesn't blow up on partially charged stacks but both
> mod_memcg_page_state and memcg_kmem_uncharge check for page->mem_cgroup
> so this is safe. Maybe a comment would save people from scratching their
> heads.
Ok, will add.
Thank you!
WARNING: multiple messages have this Message-ID (diff)
From: Roman Gushchin <guro@fb.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: <linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>,
<kernel-team@fb.com>, Johannes Weiner <hannes@cmpxchg.org>,
Andy Lutomirski <luto@kernel.org>,
Konstantin Khlebnikov <koct9i@gmail.com>,
Tejun Heo <tj@kernel.org>, Shakeel Butt <shakeelb@google.com>
Subject: Re: [PATCH v2 1/3] mm: rework memcg kernel stack accounting
Date: Thu, 23 Aug 2018 09:23:50 -0700 [thread overview]
Message-ID: <20180823162347.GA22650@tower.DHCP.thefacebook.com> (raw)
In-Reply-To: <20180822141213.GO29735@dhcp22.suse.cz>
On Wed, Aug 22, 2018 at 04:12:13PM +0200, Michal Hocko wrote:
> On Tue 21-08-18 14:35:57, Roman Gushchin wrote:
> > If CONFIG_VMAP_STACK is set, kernel stacks are allocated
> > using __vmalloc_node_range() with __GFP_ACCOUNT. So kernel
> > stack pages are charged against corresponding memory cgroups
> > on allocation and uncharged on releasing them.
> >
> > The problem is that we do cache kernel stacks in small
> > per-cpu caches and do reuse them for new tasks, which can
> > belong to different memory cgroups.
> >
> > Each stack page still holds a reference to the original cgroup,
> > so the cgroup can't be released until the vmap area is released.
> >
> > To make this happen we need more than two subsequent exits
> > without forks in between on the current cpu, which makes it
> > very unlikely to happen. As a result, I saw a significant number
> > of dying cgroups (in theory, up to 2 * number_of_cpu +
> > number_of_tasks), which can't be released even by significant
> > memory pressure.
> >
> > As a cgroup structure can take a significant amount of memory
> > (first of all, per-cpu data like memcg statistics), it leads
> > to a noticeable waste of memory.
> >
> > Signed-off-by: Roman Gushchin <guro@fb.com>
> > Cc: Johannes Weiner <hannes@cmpxchg.org>
> > Cc: Michal Hocko <mhocko@kernel.org>
> > Cc: Andy Lutomirski <luto@kernel.org>
> > Cc: Konstantin Khlebnikov <koct9i@gmail.com>
> > Cc: Tejun Heo <tj@kernel.org>
> > Cc: Shakeel Butt <shakeelb@google.com>
>
> Looks good to me. Two nits below.
>
> I am not sure stable tree backport is really needed but it would be nice
> to put
> Fixes: ac496bf48d97 ("fork: Optimize task creation by caching two thread stacks per CPU if CONFIG_VMAP_STACK=y")
>
> Acked-by: Michal Hocko <mhocko@suse.com>
Will add, thanks!
>
> > @@ -248,9 +253,20 @@ static unsigned long *alloc_thread_stack_node(struct task_struct *tsk, int node)
> > static inline void free_thread_stack(struct task_struct *tsk)
> > {
> > #ifdef CONFIG_VMAP_STACK
> > - if (task_stack_vm_area(tsk)) {
> > + struct vm_struct *vm = task_stack_vm_area(tsk);
> > +
> > + if (vm) {
> > int i;
> >
> > + for (i = 0; i < THREAD_SIZE / PAGE_SIZE; i++) {
> > + mod_memcg_page_state(vm->pages[i],
> > + MEMCG_KERNEL_STACK_KB,
> > + -(int)(PAGE_SIZE / 1024));
> > +
> > + memcg_kmem_uncharge(vm->pages[i],
> > + compound_order(vm->pages[i]));
>
> when do we have order > 0 here?
I guess, it's not possible, but hard-coded 1 looked a bit crappy.
Do you think it's better?
> Also I was wondering how come this
> doesn't blow up on partially charged stacks but both
> mod_memcg_page_state and memcg_kmem_uncharge check for page->mem_cgroup
> so this is safe. Maybe a comment would save people from scratching their
> heads.
Ok, will add.
Thank you!
next prev parent reply other threads:[~2018-08-23 16:24 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-21 21:35 [PATCH v2 1/3] mm: rework memcg kernel stack accounting Roman Gushchin
2018-08-21 21:35 ` Roman Gushchin
2018-08-21 21:35 ` [PATCH v2 2/3] mm: drain memcg stocks on css offlining Roman Gushchin
2018-08-21 21:35 ` Roman Gushchin
2018-08-21 21:35 ` [PATCH v2 3/3] mm: don't miss the last page because of round-off error Roman Gushchin
2018-08-21 21:35 ` Roman Gushchin
2018-08-21 22:10 ` [PATCH v2 1/3] mm: rework memcg kernel stack accounting Shakeel Butt
2018-08-21 22:15 ` Roman Gushchin
2018-08-21 22:15 ` Roman Gushchin
2018-08-29 21:24 ` Roman Gushchin
2018-08-29 21:24 ` Roman Gushchin
2018-08-29 21:30 ` Shakeel Butt
2018-08-22 14:12 ` Michal Hocko
2018-08-23 16:23 ` Roman Gushchin [this message]
2018-08-23 16:23 ` Roman Gushchin
2018-08-24 7:52 ` Michal Hocko
2018-08-24 12:50 ` Johannes Weiner
2018-08-24 15:42 ` Roman Gushchin
2018-08-24 15:42 ` Roman Gushchin
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=20180823162347.GA22650@tower.DHCP.thefacebook.com \
--to=guro@fb.com \
--cc=hannes@cmpxchg.org \
--cc=kernel-team@fb.com \
--cc=koct9i@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=mhocko@kernel.org \
--cc=shakeelb@google.com \
--cc=tj@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.