From: Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
To: Michal Hocko <mhocko-AlSwsSmVLrQ@public.gmane.org>
Cc: cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>,
kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org
Subject: Re: [PATCH v3 4/6] memcg: replace cgroup_lock with memcg specific memcg_lock
Date: Mon, 21 Jan 2013 20:12:17 +0400 [thread overview]
Message-ID: <50FD68E1.2070303@parallels.com> (raw)
In-Reply-To: <20130121160731.GQ7798-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
On 01/21/2013 08:07 PM, Michal Hocko wrote:
>> > And the reason why kmemcg holds the set_limit mutex
>> > is just to protect from itself, then there is no *need* to hold any
>> > extra lock (and we'll never be able to stop holding the creation lock,
>> > whatever it is). So my main point here is not memcg_mutex vs
>> > set_limit_mutex, but rather, memcg_mutex is needed anyway, and once it
>> > is taken, the set_limit_mutex *can* be held, but doesn't need to.
> So you can update kmem specific usage of set_limit_mutex.
Meaning ?
WARNING: multiple messages have this Message-ID (diff)
From: Glauber Costa <glommer@parallels.com>
To: Michal Hocko <mhocko@suse.cz>
Cc: cgroups@vger.kernel.org, linux-mm@kvack.org,
Tejun Heo <tj@kernel.org>, Johannes Weiner <hannes@cmpxchg.org>,
kamezawa.hiroyu@jp.fujitsu.com
Subject: Re: [PATCH v3 4/6] memcg: replace cgroup_lock with memcg specific memcg_lock
Date: Mon, 21 Jan 2013 20:12:17 +0400 [thread overview]
Message-ID: <50FD68E1.2070303@parallels.com> (raw)
In-Reply-To: <20130121160731.GQ7798@dhcp22.suse.cz>
On 01/21/2013 08:07 PM, Michal Hocko wrote:
>> > And the reason why kmemcg holds the set_limit mutex
>> > is just to protect from itself, then there is no *need* to hold any
>> > extra lock (and we'll never be able to stop holding the creation lock,
>> > whatever it is). So my main point here is not memcg_mutex vs
>> > set_limit_mutex, but rather, memcg_mutex is needed anyway, and once it
>> > is taken, the set_limit_mutex *can* be held, but doesn't need to.
> So you can update kmem specific usage of set_limit_mutex.
Meaning ?
--
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 prev parent reply other threads:[~2013-01-21 16:12 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-21 11:13 [PATCH v3 0/6] replace cgroup_lock with memcg specific locking Glauber Costa
2013-01-21 11:13 ` [PATCH v3 1/6] memcg: prevent changes to move_charge_at_immigrate during task attach Glauber Costa
2013-01-21 11:13 ` [PATCH v3 2/6] memcg: split part of memcg creation to css_online Glauber Costa
[not found] ` <1358766813-15095-3-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2013-01-21 13:56 ` Michal Hocko
2013-01-21 13:56 ` Michal Hocko
2013-01-21 11:13 ` [PATCH v3 3/6] memcg: fast hierarchy-aware child test Glauber Costa
2013-01-21 14:10 ` Michal Hocko
2013-01-21 11:13 ` [PATCH v3 4/6] memcg: replace cgroup_lock with memcg specific memcg_lock Glauber Costa
[not found] ` <1358766813-15095-5-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2013-01-21 14:49 ` Michal Hocko
2013-01-21 14:49 ` Michal Hocko
[not found] ` <20130121144919.GO7798-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-01-21 15:12 ` Glauber Costa
2013-01-21 15:12 ` Glauber Costa
2013-01-21 15:20 ` Michal Hocko
[not found] ` <20130121152032.GP7798-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-01-21 15:34 ` Glauber Costa
2013-01-21 15:34 ` Glauber Costa
[not found] ` <50FD6003.8060703-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2013-01-21 16:07 ` Michal Hocko
2013-01-21 16:07 ` Michal Hocko
[not found] ` <20130121160731.GQ7798-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-01-21 16:12 ` Glauber Costa [this message]
2013-01-21 16:12 ` Glauber Costa
2013-01-21 16:33 ` Michal Hocko
[not found] ` <20130121163349.GR7798-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-01-21 17:37 ` Michal Hocko
2013-01-21 17:37 ` Michal Hocko
2013-01-21 11:13 ` [PATCH v3 5/6] memcg: increment static branch right after limit set Glauber Costa
2013-01-21 11:13 ` [PATCH v3 6/6] memcg: avoid dangling reference count in creation failure Glauber Costa
[not found] ` <1358766813-15095-7-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2013-01-21 12:30 ` Michal Hocko
2013-01-21 12:30 ` Michal Hocko
[not found] ` <20130121123057.GH7798-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-01-21 13:08 ` Glauber Costa
2013-01-21 13:08 ` Glauber Costa
[not found] ` <50FD3DD4.5050309-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2013-01-21 13:19 ` Michal Hocko
2013-01-21 13:19 ` Michal Hocko
[not found] ` <20130121131921.GK7798-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2013-01-21 13:26 ` Glauber Costa
2013-01-21 13:26 ` Glauber Costa
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=50FD68E1.2070303@parallels.com \
--to=glommer-bzqdu9zft3wakbo8gow8eq@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org \
--cc=kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org \
--cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
--cc=mhocko-AlSwsSmVLrQ@public.gmane.org \
--cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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 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.