Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp483939imm; Wed, 15 Aug 2018 00:13:39 -0700 (PDT) X-Google-Smtp-Source: AA+uWPzkvX8vYA/2GFZ8WM3mCiDqH4Lbu/vybKnAXmFMTKzJk7jHXHaqP2RltFRlbCVrEn5gjZtK X-Received: by 2002:a62:4fd9:: with SMTP id f86-v6mr26332853pfj.110.1534317219083; Wed, 15 Aug 2018 00:13:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1534317219; cv=none; d=google.com; s=arc-20160816; b=JPy0FRpwnbhxyes4Yn14tyd4TMhblCC9cKC0rxirpW/X1321M9pRXC2fpKXqB7xNo4 5dk9WFpKc3sfu7epQKslVkH7odGDbmCjt4f7F494oKeBpmu/9YxBYBJ85dC+k3CoT8Us 5NLgTB4gI8Nq0rmi4c3VUU35JdDkM7vI4fDEScNyinROUNgvAbdNCswoxmK+bIlMvwzP RTA1w6xUSp7LrpZRhjTf3+/kpx6JDFGrrjM+uIJhlCHlmLkmrFlxRb78J6d7nssOc4C2 iz4PBys5IKrxP3T50EdfkgryIC0uGgPrbcGl8BPTLrMzt6IJ4mFvjZ7GA8RJY5ouCCcg LgPA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=L5ioLiGN/MkyahFRVR1onsBA65dSf7nr4AXt+jrenaQ=; b=Q0u0v2CUFPZiQYGcER3KDm5gDNu/9AJtkuYqLvCl1j0jbaRa1+9+4/b8ZkFpEKQYf8 JzqsOlYVda2hfpRkRcVDpVZO3XA9qQzIGPJ5oTGepUqV5sQZHB5asBSBciGRSaB0mUBk 2JvYHf0ZaTm/C8iULMHWyuvGn4BzZd7L3iA55cJfgMDJG5cuRgTaKDBL7+MBo42+qJBg KjJV4cO+8kZspLcqPlMKvv7+UEsOKeCGEuk9J9SsSf6cpZwv5Rmdc5MQS09DJpcrmfm/ S3NzLWgidevucgCo/RXFypZQXKWzSfRmaWRWeiE5D5tKpD8qDnP1oEJXgv9G/QrCVsgE L4fQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z19-v6si21716066pgi.388.2018.08.15.00.13.23; Wed, 15 Aug 2018 00:13:39 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728851AbeHOKB7 (ORCPT + 99 others); Wed, 15 Aug 2018 06:01:59 -0400 Received: from mx2.suse.de ([195.135.220.15]:52800 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726014AbeHOKB7 (ORCPT ); Wed, 15 Aug 2018 06:01:59 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id D09E1ADE8; Wed, 15 Aug 2018 07:10:58 +0000 (UTC) Date: Wed, 15 Aug 2018 09:10:58 +0200 From: Michal Hocko To: Roman Gushchin Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@fb.com, Johannes Weiner , Andy Lutomirski , Konstantin Khlebnikov , Tejun Heo Subject: Re: [RFC PATCH 1/2] mm: rework memcg kernel stack accounting Message-ID: <20180815071058.GL32645@dhcp22.suse.cz> References: <20180815003620.15678-1-guro@fb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180815003620.15678-1-guro@fb.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 14-08-18 17:36:19, 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 Fixes: ac496bf48d97 ("fork: Optimize task creation by caching two thread stacks per CPU if CONFIG_VMAP_STACK=y") AFAICS > Cc: Johannes Weiner > Cc: Michal Hocko > Cc: Andy Lutomirski > Cc: Konstantin Khlebnikov > Cc: Tejun Heo Yes this is the right way to do accounting here. Acked-by: Michal Hocko Thanks! > --- > kernel/fork.c | 44 ++++++++++++++++++++++++++++++++++++++------ > 1 file changed, 38 insertions(+), 6 deletions(-) > > diff --git a/kernel/fork.c b/kernel/fork.c > index 69b6fea5a181..91872b2b37bd 100644 > --- a/kernel/fork.c > +++ b/kernel/fork.c > @@ -224,9 +224,14 @@ static unsigned long *alloc_thread_stack_node(struct task_struct *tsk, int node) > return s->addr; > } > > + /* > + * Allocated stacks are cached and later reused by new threads, > + * so memcg accounting is performed manually on assigning/releasing > + * stacks to tasks. Drop __GFP_ACCOUNT. > + */ > stack = __vmalloc_node_range(THREAD_SIZE, THREAD_ALIGN, > VMALLOC_START, VMALLOC_END, > - THREADINFO_GFP, > + THREADINFO_GFP & ~__GFP_ACCOUNT, > PAGE_KERNEL, > 0, node, __builtin_return_address(0)); > > @@ -246,12 +251,41 @@ static unsigned long *alloc_thread_stack_node(struct task_struct *tsk, int node) > #endif > } > > +static void memcg_charge_kernel_stack(struct task_struct *tsk) > +{ > +#ifdef CONFIG_VMAP_STACK > + struct vm_struct *vm = task_stack_vm_area(tsk); > + > + if (vm) { > + int i; > + > + for (i = 0; i < THREAD_SIZE / PAGE_SIZE; i++) > + memcg_kmem_charge(vm->pages[i], __GFP_NOFAIL, > + compound_order(vm->pages[i])); > + > + /* All stack pages belong to the same memcg. */ > + mod_memcg_page_state(vm->pages[0], MEMCG_KERNEL_STACK_KB, > + THREAD_SIZE / 1024); > + } > +#endif > +} > + > 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; > > + /* All stack pages belong to the same memcg. */ > + mod_memcg_page_state(vm->pages[0], MEMCG_KERNEL_STACK_KB, > + -(int)(THREAD_SIZE / 1024)); > + > + for (i = 0; i < THREAD_SIZE / PAGE_SIZE; i++) > + memcg_kmem_uncharge(vm->pages[i], > + compound_order(vm->pages[i])); > + > for (i = 0; i < NR_CACHED_STACKS; i++) { > if (this_cpu_cmpxchg(cached_stacks[i], > NULL, tsk->stack_vm_area) != NULL) > @@ -352,10 +386,6 @@ static void account_kernel_stack(struct task_struct *tsk, int account) > NR_KERNEL_STACK_KB, > PAGE_SIZE / 1024 * account); > } > - > - /* All stack pages belong to the same memcg. */ > - mod_memcg_page_state(vm->pages[0], MEMCG_KERNEL_STACK_KB, > - account * (THREAD_SIZE / 1024)); > } else { > /* > * All stack pages are in the same zone and belong to the > @@ -809,6 +839,8 @@ static struct task_struct *dup_task_struct(struct task_struct *orig, int node) > if (!stack) > goto free_tsk; > > + memcg_charge_kernel_stack(tsk); > + > stack_vm_area = task_stack_vm_area(tsk); > > err = arch_dup_task_struct(tsk, orig); > -- > 2.14.4 -- Michal Hocko SUSE Labs