From: Tejun Heo <tj@kernel.org>
To: Hugh Dickins <hughd@google.com>
Cc: Michal Hocko <mhocko@suse.cz>,
Johannes Weiner <hannes@cmpxchg.org>,
Filipe Brandenburger <filbranden@google.com>,
Li Zefan <lizefan@huawei.com>,
Andrew Morton <akpm@linux-foundation.org>,
Greg Thelen <gthelen@google.com>,
Michel Lespinasse <walken@google.com>,
Markus Blank-Burian <burian@muenster.de>,
Shawn Bohrer <shawn.bohrer@gmail.com>,
cgroups@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [PATCH 2/2] cgroup: bring back kill_cnt to order css destruction
Date: Wed, 12 Feb 2014 19:28:53 -0500 [thread overview]
Message-ID: <20140213002853.GC2916@htj.dyndns.org> (raw)
In-Reply-To: <alpine.LSU.2.11.1402121504150.5029@eggly.anvils>
Hello, Hugh.
On Wed, Feb 12, 2014 at 03:06:26PM -0800, Hugh Dickins wrote:
> 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().
>
> Further testing showed that an ordered workqueue for cgroup_destroy_wq
> is not always good enough: percpu_ref_kill_and_confirm's call_rcu_sched
> stage on the way can mess up the order before reaching the workqueue.
>
> Instead bring back v3.11's css kill_cnt, repurposing it to make sure
> that offline_css() is not called for parent before it has been called
> for all children.
>
> Fixes: e5fca243abae ("cgroup: use a dedicated workqueue for cgroup destruction")
> Signed-off-by: Hugh Dickins <hughd@google.com>
> Reviewed-by: Filipe Brandenburger <filbranden@google.com>
> Cc: stable@vger.kernel.org # v3.10+ (but will need extra care)
> ---
> This is an alternative to Filipe's 1/2: there's no need for both,
> but each has its merits. I prefer Filipe's, which is much easier to
> understand: this one made more sense in v3.11, when it was just a matter
> of extending the use of css_kill_cnt; but might be preferred if offlining
> children before parent is thought to be a good idea generally.
Not that your implementation is bad or anything but the patch itself
somehow makes me cringe a bit. It's probably just because it has to
add to the already overly complicated offline path. Guaranteeing
strict offline ordering might be a good idea but at least for the
immediate bug fix, I agree that the memcg specific fix seems better
suited. Let's apply that one and reconsider this one if it turns out
we do need strict offline reordering.
Thanks a lot!
--
tejun
--
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Tejun Heo <tj@kernel.org>
To: Hugh Dickins <hughd@google.com>
Cc: Michal Hocko <mhocko@suse.cz>,
Johannes Weiner <hannes@cmpxchg.org>,
Filipe Brandenburger <filbranden@google.com>,
Li Zefan <lizefan@huawei.com>,
Andrew Morton <akpm@linux-foundation.org>,
Greg Thelen <gthelen@google.com>,
Michel Lespinasse <walken@google.com>,
Markus Blank-Burian <burian@muenster.de>,
Shawn Bohrer <shawn.bohrer@gmail.com>,
cgroups@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [PATCH 2/2] cgroup: bring back kill_cnt to order css destruction
Date: Wed, 12 Feb 2014 19:28:53 -0500 [thread overview]
Message-ID: <20140213002853.GC2916@htj.dyndns.org> (raw)
In-Reply-To: <alpine.LSU.2.11.1402121504150.5029@eggly.anvils>
Hello, Hugh.
On Wed, Feb 12, 2014 at 03:06:26PM -0800, Hugh Dickins wrote:
> 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().
>
> Further testing showed that an ordered workqueue for cgroup_destroy_wq
> is not always good enough: percpu_ref_kill_and_confirm's call_rcu_sched
> stage on the way can mess up the order before reaching the workqueue.
>
> Instead bring back v3.11's css kill_cnt, repurposing it to make sure
> that offline_css() is not called for parent before it has been called
> for all children.
>
> Fixes: e5fca243abae ("cgroup: use a dedicated workqueue for cgroup destruction")
> Signed-off-by: Hugh Dickins <hughd@google.com>
> Reviewed-by: Filipe Brandenburger <filbranden@google.com>
> Cc: stable@vger.kernel.org # v3.10+ (but will need extra care)
> ---
> This is an alternative to Filipe's 1/2: there's no need for both,
> but each has its merits. I prefer Filipe's, which is much easier to
> understand: this one made more sense in v3.11, when it was just a matter
> of extending the use of css_kill_cnt; but might be preferred if offlining
> children before parent is thought to be a good idea generally.
Not that your implementation is bad or anything but the patch itself
somehow makes me cringe a bit. It's probably just because it has to
add to the already overly complicated offline path. Guaranteeing
strict offline ordering might be a good idea but at least for the
immediate bug fix, I agree that the memcg specific fix seems better
suited. Let's apply that one and reconsider this one if it turns out
we do need strict offline reordering.
Thanks a lot!
--
tejun
next prev parent reply other threads:[~2014-02-13 0:28 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-06 23:56 [PATCH] cgroup: use an ordered workqueue for cgroup destruction Hugh Dickins
2014-02-06 23:56 ` Hugh Dickins
2014-02-06 23:56 ` Hugh Dickins
2014-02-07 14:04 ` Tejun Heo
2014-02-07 14:04 ` Tejun Heo
2014-02-07 14:37 ` Michal Hocko
2014-02-07 14:37 ` Michal Hocko
[not found] ` <20140207143740.GD5121-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2014-02-07 15:13 ` Tejun Heo
2014-02-07 15:13 ` Tejun Heo
2014-02-07 15:13 ` Tejun Heo
2014-02-07 15:28 ` Michal Hocko
2014-02-07 15:28 ` Michal Hocko
[not found] ` <20140207140402.GA3304-Gd/HAXX7CRxy/B6EtB590w@public.gmane.org>
2014-02-07 20:20 ` Hugh Dickins
2014-02-07 20:20 ` Hugh Dickins
2014-02-07 20:20 ` Hugh Dickins
2014-02-07 20:35 ` Tejun Heo
2014-02-07 20:35 ` Tejun Heo
2014-02-07 21:06 ` Hugh Dickins
2014-02-07 21:06 ` Hugh Dickins
2014-02-07 15:21 ` Tejun Heo
2014-02-07 15:21 ` Tejun Heo
[not found] ` <alpine.LSU.2.11.1402061541560.31342-fupSdm12i1nKWymIFiNcPA@public.gmane.org>
2014-02-07 13:45 ` Michal Hocko
2014-02-07 13:45 ` Michal Hocko
2014-02-07 13:45 ` Michal Hocko
2014-02-07 16:43 ` Johannes Weiner
2014-02-07 16:43 ` Johannes Weiner
2014-02-07 16:43 ` Johannes Weiner
[not found] ` <20140207164321.GE6963-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2014-02-10 15:46 ` Michal Hocko
2014-02-10 15:46 ` Michal Hocko
2014-02-10 15:46 ` Michal Hocko
2014-02-12 22:59 ` Hugh Dickins
2014-02-12 22:59 ` Hugh Dickins
2014-02-12 22:59 ` Hugh Dickins
[not found] ` <alpine.LSU.2.11.1402121417230.5029-fupSdm12i1nKWymIFiNcPA@public.gmane.org>
2014-02-12 23:06 ` [PATCH 2/2] cgroup: bring back kill_cnt to order css destruction Hugh Dickins
2014-02-12 23:06 ` Hugh Dickins
2014-02-12 23:06 ` Hugh Dickins
2014-02-13 0:28 ` Tejun Heo [this message]
2014-02-13 0:28 ` Tejun Heo
2014-02-13 0:38 ` Hugh Dickins
2014-02-13 0:38 ` Hugh Dickins
2014-02-13 0:09 ` [PATCH] Revert "cgroup: use an ordered workqueue for cgroup destruction" Tejun Heo
2014-02-13 0:09 ` Tejun Heo
2014-02-13 0:09 ` Tejun Heo
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=20140213002853.GC2916@htj.dyndns.org \
--to=tj@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=burian@muenster.de \
--cc=cgroups@vger.kernel.org \
--cc=filbranden@google.com \
--cc=gthelen@google.com \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lizefan@huawei.com \
--cc=mhocko@suse.cz \
--cc=shawn.bohrer@gmail.com \
--cc=walken@google.com \
/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.