From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hugh Dickins Subject: [PATCH] cgroup: use an ordered workqueue for cgroup destruction Date: Thu, 6 Feb 2014 15:56:01 -0800 (PST) Message-ID: Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:user-agent:mime-version :content-type; bh=zQFKSQ8jffFU9JESzBget+N5hhvrD8Y5cfzNB9VmMas=; b=jH5++37asInks8MH5ZqUvc6oVAbGgcvziH2DjdeGAbrhcquCojq11hYtG8c3I11TyZ r6cuxp6aBvbg6pNJaYBj3f04O5eBGvi6w5wV3e8srxE6GAItcl/BAprXSoz1TookLNVL YueIrhdr7ClP5heSCcPz/5ya6wu3VzOV54UzvGYQjWMicHAGsxbwvWTOsCYXCvYX6gRI hbM8a9w7unxm4a0kPZAMeJaZsQ+3Ax7mnuX7NKv9J2ttg+PZCEH7vkQCQ/ukxjX4JCYB JFvpQjiZdyG8h0FBQwdYCh9i3Jqrf/fIrxBkpcX/4kkdAdwNeSX8A8V6BrfHEXU2f8cW AakQ== Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: TEXT/PLAIN; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Tejun Heo Cc: Filipe Brandenburger , Li Zefan , Andrew Morton , Michal Hocko , Johannes Weiner , Greg Thelen , Michel Lespinasse , Markus Blank-Burian , Shawn Bohrer , cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org Sometimes the cleanup after memcg hierarchy testing gets stuck in mem_cgroup_reparent_charges(), unable to bring non-kmem usage down to 0. There may turn out to be several causes, but a major cause is this: the workitem to offline parent can get run before workitem to offline child; parent's mem_cgroup_reparent_charges() circles around waiting for the child's pages to be reparented to its lrus, but it's holding cgroup_mutex which prevents the child from reaching its mem_cgroup_reparent_charges(). Just use an ordered workqueue for cgroup_destroy_wq. Fixes: e5fca243abae ("cgroup: use a dedicated workqueue for cgroup destruction") Suggested-by: Filipe Brandenburger Signed-off-by: Hugh Dickins Cc: stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org # 3.10+ --- kernel/cgroup.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- 3.14-rc1/kernel/cgroup.c 2014-02-02 18:49:07.737302111 -0800 +++ linux/kernel/cgroup.c 2014-02-06 15:20:35.548904965 -0800 @@ -4845,12 +4845,12 @@ static int __init cgroup_wq_init(void) /* * There isn't much point in executing destruction path in * parallel. Good chunk is serialized with cgroup_mutex anyway. - * Use 1 for @max_active. + * Must be ordered to make sure parent is offlined after children. * * We would prefer to do this in cgroup_init() above, but that * is called before init_workqueues(): so leave this until after. */ - cgroup_destroy_wq = alloc_workqueue("cgroup_destroy", 0, 1); + cgroup_destroy_wq = alloc_ordered_workqueue("cgroup_destroy", 0); BUG_ON(!cgroup_destroy_wq); /* From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pb0-f46.google.com (mail-pb0-f46.google.com [209.85.160.46]) by kanga.kvack.org (Postfix) with ESMTP id 1B4EA6B0037 for ; Thu, 6 Feb 2014 18:57:15 -0500 (EST) Received: by mail-pb0-f46.google.com with SMTP id um1so2470957pbc.33 for ; Thu, 06 Feb 2014 15:57:14 -0800 (PST) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [2607:f8b0:400e:c01::22d]) by mx.google.com with ESMTPS id tq5si2745989pac.182.2014.02.06.15.57.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Feb 2014 15:57:12 -0800 (PST) Received: by mail-pb0-f45.google.com with SMTP id un15so2444148pbc.18 for ; Thu, 06 Feb 2014 15:57:11 -0800 (PST) Date: Thu, 6 Feb 2014 15:56:01 -0800 (PST) From: Hugh Dickins Subject: [PATCH] cgroup: use an ordered workqueue for cgroup destruction Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: Tejun Heo Cc: Filipe Brandenburger , Li Zefan , Andrew Morton , Michal Hocko , Johannes Weiner , Greg Thelen , Michel Lespinasse , Markus Blank-Burian , Shawn Bohrer , cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Sometimes the cleanup after memcg hierarchy testing gets stuck in mem_cgroup_reparent_charges(), unable to bring non-kmem usage down to 0. There may turn out to be several causes, but a major cause is this: the workitem to offline parent can get run before workitem to offline child; parent's mem_cgroup_reparent_charges() circles around waiting for the child's pages to be reparented to its lrus, but it's holding cgroup_mutex which prevents the child from reaching its mem_cgroup_reparent_charges(). Just use an ordered workqueue for cgroup_destroy_wq. Fixes: e5fca243abae ("cgroup: use a dedicated workqueue for cgroup destruction") Suggested-by: Filipe Brandenburger Signed-off-by: Hugh Dickins Cc: stable@vger.kernel.org # 3.10+ --- kernel/cgroup.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- 3.14-rc1/kernel/cgroup.c 2014-02-02 18:49:07.737302111 -0800 +++ linux/kernel/cgroup.c 2014-02-06 15:20:35.548904965 -0800 @@ -4845,12 +4845,12 @@ static int __init cgroup_wq_init(void) /* * There isn't much point in executing destruction path in * parallel. Good chunk is serialized with cgroup_mutex anyway. - * Use 1 for @max_active. + * Must be ordered to make sure parent is offlined after children. * * We would prefer to do this in cgroup_init() above, but that * is called before init_workqueues(): so leave this until after. */ - cgroup_destroy_wq = alloc_workqueue("cgroup_destroy", 0, 1); + cgroup_destroy_wq = alloc_ordered_workqueue("cgroup_destroy", 0); BUG_ON(!cgroup_destroy_wq); /* -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751501AbaBFX5O (ORCPT ); Thu, 6 Feb 2014 18:57:14 -0500 Received: from mail-pb0-f53.google.com ([209.85.160.53]:47518 "EHLO mail-pb0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751004AbaBFX5M (ORCPT ); Thu, 6 Feb 2014 18:57:12 -0500 Date: Thu, 6 Feb 2014 15:56:01 -0800 (PST) From: Hugh Dickins X-X-Sender: hugh@eggly.anvils To: Tejun Heo cc: Filipe Brandenburger , Li Zefan , Andrew Morton , Michal Hocko , Johannes Weiner , Greg Thelen , Michel Lespinasse , Markus Blank-Burian , Shawn Bohrer , cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH] cgroup: use an ordered workqueue for cgroup destruction Message-ID: User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Sometimes the cleanup after memcg hierarchy testing gets stuck in mem_cgroup_reparent_charges(), unable to bring non-kmem usage down to 0. There may turn out to be several causes, but a major cause is this: the workitem to offline parent can get run before workitem to offline child; parent's mem_cgroup_reparent_charges() circles around waiting for the child's pages to be reparented to its lrus, but it's holding cgroup_mutex which prevents the child from reaching its mem_cgroup_reparent_charges(). Just use an ordered workqueue for cgroup_destroy_wq. Fixes: e5fca243abae ("cgroup: use a dedicated workqueue for cgroup destruction") Suggested-by: Filipe Brandenburger Signed-off-by: Hugh Dickins Cc: stable@vger.kernel.org # 3.10+ --- kernel/cgroup.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- 3.14-rc1/kernel/cgroup.c 2014-02-02 18:49:07.737302111 -0800 +++ linux/kernel/cgroup.c 2014-02-06 15:20:35.548904965 -0800 @@ -4845,12 +4845,12 @@ static int __init cgroup_wq_init(void) /* * There isn't much point in executing destruction path in * parallel. Good chunk is serialized with cgroup_mutex anyway. - * Use 1 for @max_active. + * Must be ordered to make sure parent is offlined after children. * * We would prefer to do this in cgroup_init() above, but that * is called before init_workqueues(): so leave this until after. */ - cgroup_destroy_wq = alloc_workqueue("cgroup_destroy", 0, 1); + cgroup_destroy_wq = alloc_ordered_workqueue("cgroup_destroy", 0); BUG_ON(!cgroup_destroy_wq); /*