Messages in this thread Patch in this message | | | Date | Thu, 6 Feb 2014 15:56:01 -0800 (PST) | From | Hugh Dickins <> | Subject | [PATCH] cgroup: use an ordered workqueue for cgroup destruction |
| |
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 <filbranden@google.com> Signed-off-by: Hugh Dickins <hughd@google.com> 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); /*
| |