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>,
kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org,
Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
Subject: Re: [PATCH 4/4] memcg: replace cgroup_lock with memcg specific memcg_lock
Date: Tue, 4 Dec 2012 12:31:31 +0400 [thread overview]
Message-ID: <50BDB4E3.4040107@parallels.com> (raw)
In-Reply-To: <20121204082316.GB31319-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
On 12/04/2012 12:23 PM, Michal Hocko wrote:
> On Tue 04-12-12 11:58:48, Glauber Costa wrote:
>> On 12/03/2012 09:15 PM, Michal Hocko wrote:
>>> On Fri 30-11-12 17:31:26, Glauber Costa wrote:
>>> [...]
>>>> +/*
>>>> + * must be called with memcg_lock held, unless the cgroup is guaranteed to be
>>>> + * already dead (like in mem_cgroup_force_empty, for instance).
>>>> + */
>>>> +static inline bool memcg_has_children(struct mem_cgroup *memcg)
>>>> +{
>>>> + return mem_cgroup_count_children(memcg) != 1;
>>>> +}
>>>
>>> Why not just keep list_empty(&cgrp->children) which is much simpler much
>>> more effective and correct here as well because cgroup cannot vanish
>>> while we are at the call because all callers come from cgroup fs?
>>>
>> Because it depends on cgroup's internal representation, which I think
>> we're better off not depending upon, even if this is not as serious a
>> case as the locking stuff. But also, technically, cgrp->children is
>> protected by the cgroup_lock(), while since we'll hold the memcg_lock
>> during creation and also around the iterators, we cover everything with
>> the same lock.
>
> The list is RCU safe so we do not have to use cgroup_lock there for this
> kind of test.
>
>> That said, of course we don't need to do the full iteration here, and
>> mem_cgroup_count_children is indeed overkill. We could just as easily
>> verify if any child exist - it is just an emptiness test after all. But
>> it is not living in any fast path, though, and I just assumed code reuse
>> to win over efficiency in this particular case -
>> mem_cgroup_count_children already existed...
>
> Yes but the function name suggests a more generic usage and the test is
> really an overkill. Maybe we can get a cgroup generic helper
> cgroup_as_children which would do the thing without exhibiting cgroup
> internals. What do you think?
>
I will give it another round of thinking, but I still don't see the
reason for calling to cgroup core with this. If you really dislike doing
a children count (I don't like as well, I just don't dislike), maybe we
can do something like:
i = 0;
for_each_mem_cgroup_tree(iter, memcg) {
if (i++ == 1)
return false;
}
return true;
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>,
kamezawa.hiroyu@jp.fujitsu.com,
Johannes Weiner <hannes@cmpxchg.org>
Subject: Re: [PATCH 4/4] memcg: replace cgroup_lock with memcg specific memcg_lock
Date: Tue, 4 Dec 2012 12:31:31 +0400 [thread overview]
Message-ID: <50BDB4E3.4040107@parallels.com> (raw)
In-Reply-To: <20121204082316.GB31319@dhcp22.suse.cz>
On 12/04/2012 12:23 PM, Michal Hocko wrote:
> On Tue 04-12-12 11:58:48, Glauber Costa wrote:
>> On 12/03/2012 09:15 PM, Michal Hocko wrote:
>>> On Fri 30-11-12 17:31:26, Glauber Costa wrote:
>>> [...]
>>>> +/*
>>>> + * must be called with memcg_lock held, unless the cgroup is guaranteed to be
>>>> + * already dead (like in mem_cgroup_force_empty, for instance).
>>>> + */
>>>> +static inline bool memcg_has_children(struct mem_cgroup *memcg)
>>>> +{
>>>> + return mem_cgroup_count_children(memcg) != 1;
>>>> +}
>>>
>>> Why not just keep list_empty(&cgrp->children) which is much simpler much
>>> more effective and correct here as well because cgroup cannot vanish
>>> while we are at the call because all callers come from cgroup fs?
>>>
>> Because it depends on cgroup's internal representation, which I think
>> we're better off not depending upon, even if this is not as serious a
>> case as the locking stuff. But also, technically, cgrp->children is
>> protected by the cgroup_lock(), while since we'll hold the memcg_lock
>> during creation and also around the iterators, we cover everything with
>> the same lock.
>
> The list is RCU safe so we do not have to use cgroup_lock there for this
> kind of test.
>
>> That said, of course we don't need to do the full iteration here, and
>> mem_cgroup_count_children is indeed overkill. We could just as easily
>> verify if any child exist - it is just an emptiness test after all. But
>> it is not living in any fast path, though, and I just assumed code reuse
>> to win over efficiency in this particular case -
>> mem_cgroup_count_children already existed...
>
> Yes but the function name suggests a more generic usage and the test is
> really an overkill. Maybe we can get a cgroup generic helper
> cgroup_as_children which would do the thing without exhibiting cgroup
> internals. What do you think?
>
I will give it another round of thinking, but I still don't see the
reason for calling to cgroup core with this. If you really dislike doing
a children count (I don't like as well, I just don't dislike), maybe we
can do something like:
i = 0;
for_each_mem_cgroup_tree(iter, memcg) {
if (i++ == 1)
return false;
}
return true;
--
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:[~2012-12-04 8:31 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-30 13:31 [PATCH 0/4] replace cgroup_lock with local lock in memcg Glauber Costa
2012-11-30 13:31 ` [PATCH 1/4] cgroup: warn about broken hierarchies only after css_online Glauber Costa
[not found] ` <1354282286-32278-2-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-11-30 15:11 ` Tejun Heo
2012-11-30 15:11 ` Tejun Heo
[not found] ` <20121130151158.GB3873-Gd/HAXX7CRxy/B6EtB590w@public.gmane.org>
2012-11-30 15:13 ` Glauber Costa
2012-11-30 15:13 ` Glauber Costa
[not found] ` <50B8CD32.4080807-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-11-30 15:45 ` Tejun Heo
2012-11-30 15:45 ` Tejun Heo
[not found] ` <20121130154504.GD3873-Gd/HAXX7CRxy/B6EtB590w@public.gmane.org>
2012-11-30 15:49 ` Michal Hocko
2012-11-30 15:49 ` Michal Hocko
2012-11-30 15:57 ` Glauber Costa
2012-11-30 13:31 ` [PATCH 2/4] memcg: prevent changes to move_charge_at_immigrate during task attach Glauber Costa
2012-11-30 15:19 ` Tejun Heo
2012-11-30 15:29 ` Glauber Costa
[not found] ` <1354282286-32278-3-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-12-04 9:29 ` Michal Hocko
2012-12-04 9:29 ` Michal Hocko
2012-11-30 13:31 ` [PATCH 3/4] memcg: split part of memcg creation to css_online Glauber Costa
[not found] ` <1354282286-32278-4-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-12-03 17:32 ` Michal Hocko
2012-12-03 17:32 ` Michal Hocko
[not found] ` <20121203173205.GI17093-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2012-12-04 8:05 ` Glauber Costa
2012-12-04 8:05 ` Glauber Costa
[not found] ` <50BDAEC1.8040805-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-12-04 8:17 ` Michal Hocko
2012-12-04 8:17 ` Michal Hocko
[not found] ` <20121204081756.GA31319-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2012-12-04 8:32 ` Glauber Costa
2012-12-04 8:32 ` Glauber Costa
[not found] ` <50BDB511.5070107-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-12-04 8:52 ` Michal Hocko
2012-12-04 8:52 ` Michal Hocko
2012-11-30 13:31 ` [PATCH 4/4] memcg: replace cgroup_lock with memcg specific memcg_lock Glauber Costa
[not found] ` <1354282286-32278-5-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-12-03 17:15 ` Michal Hocko
2012-12-03 17:15 ` Michal Hocko
[not found] ` <20121203171532.GG17093-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2012-12-03 17:30 ` Michal Hocko
2012-12-03 17:30 ` Michal Hocko
[not found] ` <20121203173002.GH17093-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2012-12-04 7:49 ` Glauber Costa
2012-12-04 7:49 ` Glauber Costa
2012-12-04 7:58 ` Glauber Costa
[not found] ` <50BDAD38.6030200-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-12-04 8:23 ` Michal Hocko
2012-12-04 8:23 ` Michal Hocko
[not found] ` <20121204082316.GB31319-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2012-12-04 8:31 ` Glauber Costa [this message]
2012-12-04 8:31 ` Glauber Costa
[not found] ` <50BDB4E3.4040107-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-12-04 8:45 ` Michal Hocko
2012-12-04 8:45 ` Michal Hocko
[not found] ` <20121204084544.GC31319-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2012-12-04 14:52 ` Tejun Heo
2012-12-04 14:52 ` Tejun Heo
[not found] ` <20121204145221.GA3885-9pTldWuhBndy/B6EtB590w@public.gmane.org>
2012-12-04 15:14 ` Michal Hocko
2012-12-04 15:14 ` Michal Hocko
[not found] ` <20121204151420.GL31319-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2012-12-04 15:22 ` Tejun Heo
2012-12-04 15:22 ` Tejun Heo
[not found] ` <20121204152225.GC3885-9pTldWuhBndy/B6EtB590w@public.gmane.org>
2012-12-05 14:35 ` Michal Hocko
2012-12-05 14:35 ` Michal Hocko
[not found] ` <20121205143537.GC9714-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2012-12-05 14:41 ` Tejun Heo
2012-12-05 14:41 ` Tejun Heo
[not found] ` <1354282286-32278-1-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-11-30 15:52 ` [PATCH 0/4] replace cgroup_lock with local lock in memcg Tejun Heo
2012-11-30 15:52 ` Tejun Heo
2012-11-30 15:59 ` 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=50BDB4E3.4040107@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.