From: Glauber Costa <glommer@parallels.com>
To: cgroups@vger.kernel.org
Cc: linux-mm@kvack.org, Tejun Heo <tj@kernel.org>,
Michal Hocko <mhocko@suse.cz>,
Johannes Weiner <hannes@cmpxchg.org>,
kamezawa.hiroyu@jp.fujitsu.com
Subject: [PATCH v4 0/6] replace cgroup_lock with memcg specific locking
Date: Tue, 22 Jan 2013 17:47:35 +0400 [thread overview]
Message-ID: <1358862461-18046-1-git-send-email-glommer@parallels.com> (raw)
Hi,
In memcg, we use the cgroup_lock basically to synchronize against
attaching new children to a cgroup. We do this because we rely on cgroup core to
provide us with this information.
We need to guarantee that upon child creation, our tunables are consistent.
For those, the calls to cgroup_lock() all live in handlers like
mem_cgroup_hierarchy_write(), where we change a tunable in the group that is
hierarchy-related. For instance, the use_hierarchy flag cannot be changed if
the cgroup already have children.
Furthermore, those values are propageted from the parent to the child when a
new child is created. So if we don't lock like this, we can end up with the
following situation:
A B
memcg_css_alloc() mem_cgroup_hierarchy_write()
copy use hierarchy from parent change use hierarchy in parent
finish creation.
This is mainly because during create, we are still not fully connected to the
css tree. So all iterators and the such that we could use, will fail to show
that the group has children.
My observation is that all of creation can proceed in parallel with those
tasks, except value assignment. So what this patchseries does is to first move
all value assignment that is dependent on parent values from css_alloc to
css_online, where the iterators all work, and then we lock only the value
assignment. This will guarantee that parent and children always have consistent
values. Together with an online test, that can be derived from the observation
that the refcount of an online memcg can be made to be always positive, we
should be able to synchronize our side without the cgroup lock.
*v4:
- revert back to using the set_limit_mutex for kmemcg limit setting.
*v3:
- simplified test for presence of children, and no longer using refcnt for
online testing
- some cleanups as suggested by Michal
*v2:
- sanitize kmemcg assignment in the light of the current locking change.
- don't grab locks on immigrate charges by caching the value during can_attach
Glauber Costa (6):
memcg: prevent changes to move_charge_at_immigrate during task attach
memcg: split part of memcg creation to css_online
memcg: fast hierarchy-aware child test.
memcg: replace cgroup_lock with memcg specific memcg_lock
memcg: increment static branch right after limit set.
memcg: avoid dangling reference count in creation failure.
mm/memcontrol.c | 193 +++++++++++++++++++++++++++++++++-----------------------
1 file changed, 114 insertions(+), 79 deletions(-)
--
1.8.1
--
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>
next reply other threads:[~2013-01-22 13:47 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-22 13:47 Glauber Costa [this message]
2013-01-22 13:47 ` [PATCH v4 1/6] memcg: prevent changes to move_charge_at_immigrate during task attach Glauber Costa
2013-01-29 0:11 ` Kamezawa Hiroyuki
2013-01-22 13:47 ` [PATCH v4 2/6] memcg: split part of memcg creation to css_online Glauber Costa
2013-01-25 23:52 ` Andrew Morton
2013-01-28 8:35 ` Lord Glauber Costa of Sealand
2013-01-29 0:12 ` Kamezawa Hiroyuki
2013-01-22 13:47 ` [PATCH v4 3/6] memcg: fast hierarchy-aware child test Glauber Costa
2013-01-25 23:59 ` Andrew Morton
2013-01-28 8:30 ` Lord Glauber Costa of Sealand
2013-01-29 0:14 ` Kamezawa Hiroyuki
2013-01-22 13:47 ` [PATCH v4 4/6] memcg: replace cgroup_lock with memcg specific memcg_lock Glauber Costa
2013-01-22 14:00 ` Michal Hocko
2013-01-29 0:16 ` Kamezawa Hiroyuki
2013-01-22 13:47 ` [PATCH v4 5/6] memcg: increment static branch right after limit set Glauber Costa
2013-01-29 0:18 ` Kamezawa Hiroyuki
2013-01-22 13:47 ` [PATCH v4 6/6] memcg: avoid dangling reference count in creation failure Glauber Costa
2013-01-22 14:00 ` Michal Hocko
2013-01-29 0:22 ` Kamezawa Hiroyuki
2013-01-25 10:05 ` [PATCH v4 0/6] replace cgroup_lock with memcg specific locking Lord Glauber Costa of Sealand
2013-01-25 10:18 ` Michal Hocko
2013-01-25 10:27 ` Lord Glauber Costa of Sealand
2013-01-25 17:37 ` Tejun Heo
2013-01-26 0:03 ` Andrew Morton
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=1358862461-18046-1-git-send-email-glommer@parallels.com \
--to=glommer@parallels.com \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.cz \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox