From: Michal Hocko <mhocko@suse.cz>
To: Glauber Costa <glommer@parallels.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Andrew Morton <akpm@linux-foundation.org>,
Mel Gorman <mgorman@suse.de>,
Suleiman Souhlal <suleiman@google.com>, Tejun Heo <tj@kernel.org>,
cgroups@vger.kernel.org, kamezawa.hiroyu@jp.fujitsu.com,
Johannes Weiner <hannes@cmpxchg.org>,
Greg Thelen <gthelen@google.com>,
devel@openvz.org, Frederic Weisbecker <fweisbec@gmail.com>
Subject: Re: [PATCH v4 08/14] res_counter: return amount of charges after res_counter_uncharge
Date: Wed, 10 Oct 2012 13:24:47 +0200 [thread overview]
Message-ID: <20121010112446.GE23011@dhcp22.suse.cz> (raw)
In-Reply-To: <507539EB.90006@parallels.com>
On Wed 10-10-12 13:03:39, Glauber Costa wrote:
> On 10/09/2012 07:35 PM, Michal Hocko wrote:
> > On Tue 09-10-12 19:14:57, Glauber Costa wrote:
> >> On 10/09/2012 07:08 PM, Michal Hocko wrote:
> >>> As I have already mentioned in my previous feedback this is cetainly not
> >>> atomic as you the lock protects only one group in the hierarchy. How is
> >>> the return value from this function supposed to be used?
> >>
> >> So, I tried to make that clearer in the updated changelog.
> >>
> >> Only the value of the base memcg (the one passed to the function) is
> >> returned, and it is atomic, in the sense that it has the same semantics
> >> as the atomic variables: If 2 threads uncharge 4k each from a 8 k
> >> counter, a subsequent read can return 0 for both. The return value here
> >> will guarantee that only one sees the drop to 0.
> >>
> >> This is used in the patch "kmem_accounting lifecycle management" to be
> >> sure that only one process will call mem_cgroup_put() in the memcg
> >> structure.
> >
> > Yes, you are using res_counter_uncharge and its semantic makes sense.
> > I was refering to res_counter_uncharge_until (you removed that context
> > from my reply) because that one can race resulting that nobody sees 0
> > even though that parents get down to 0 as a result:
> > A
> > |
> > B
> > / \
> > C(x) D(y)
> >
> > D and C uncharge everything.
> >
> > CPU0 CPU1
> > ret += uncharge(D) [0] ret += uncharge(C) [0]
> > ret += uncharge(B) [x-from C]
> > ret += uncharge(B) [0]
> > ret += uncharge(A) [y-from D]
> > ret += uncharge(A) [0]
> >
> > ret == x ret == y
> >
>
> Sorry Michal, I didn't realize you were talking about
> res_counter_uncharge_until.
I could have been more specific.
> I don't really need res_counter_uncharge_until to return anything, so I
> can just remove that if you prefer, keeping just the main
> res_counter_uncharge.
>
> However, I still can't make sense of your concern.
>
> The return value will return the value of the counter passed as a
> parameter to the function:
>
> r = res_counter_uncharge_locked(c, val);
> if (c == counter)
> ret = r;
Dohh. I have no idea where I took ret += r from. Sorry about the noise.
> So when you call res_counter_uncharge_until(D, whatever, x), you will
> see zero here as a result, and when you call
> res_counter_uncharge_until(D, whatever, y) you will see 0 here as well.
>
> A doesn't get involved with that.
You are right.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2012-10-10 11:24 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-08 10:06 [PATCH v4 00/14] kmem controller for memcg Glauber Costa
2012-10-08 10:06 ` [PATCH v4 01/14] memcg: Make it possible to use the stock for more than one page Glauber Costa
2012-10-08 10:06 ` [PATCH v4 02/14] memcg: Reclaim when more than one page needed Glauber Costa
2012-10-16 3:22 ` Kamezawa Hiroyuki
2012-10-08 10:06 ` [PATCH v4 03/14] memcg: change defines to an enum Glauber Costa
2012-10-08 10:06 ` [PATCH v4 04/14] kmem accounting basic infrastructure Glauber Costa
2012-10-11 10:11 ` Michal Hocko
2012-10-11 12:53 ` Michal Hocko
2012-10-11 13:38 ` Michal Hocko
2012-10-12 7:36 ` Glauber Costa
2012-10-12 8:27 ` Michal Hocko
2012-10-08 10:06 ` [PATCH v4 05/14] Add a __GFP_KMEMCG flag Glauber Costa
2012-10-09 15:04 ` Michal Hocko
2012-10-08 10:06 ` [PATCH v4 06/14] memcg: kmem controller infrastructure Glauber Costa
2012-10-11 12:42 ` Michal Hocko
2012-10-11 12:56 ` Michal Hocko
2012-10-12 7:45 ` Glauber Costa
2012-10-12 8:39 ` Michal Hocko
2012-10-12 8:44 ` Glauber Costa
2012-10-12 8:57 ` Michal Hocko
2012-10-12 9:13 ` Glauber Costa
2012-10-12 9:47 ` Michal Hocko
2012-10-16 8:00 ` Kamezawa Hiroyuki
2012-10-08 10:06 ` [PATCH v4 07/14] mm: Allocate kernel pages to the right memcg Glauber Costa
2012-10-08 10:06 ` [PATCH v4 08/14] res_counter: return amount of charges after res_counter_uncharge Glauber Costa
2012-10-09 15:08 ` Michal Hocko
2012-10-09 15:14 ` Glauber Costa
2012-10-09 15:35 ` Michal Hocko
2012-10-10 9:03 ` Glauber Costa
2012-10-10 11:24 ` Michal Hocko [this message]
2012-10-10 11:25 ` Michal Hocko
2012-10-16 8:20 ` Kamezawa Hiroyuki
2012-10-08 10:06 ` [PATCH v4 09/14] memcg: kmem accounting lifecycle management Glauber Costa
2012-10-11 13:11 ` Michal Hocko
2012-10-12 7:47 ` Glauber Costa
2012-10-12 8:41 ` Michal Hocko
2012-10-16 8:41 ` Kamezawa Hiroyuki
2012-10-08 10:06 ` [PATCH v4 10/14] memcg: use static branches when code not in use Glauber Costa
2012-10-11 13:40 ` Michal Hocko
2012-10-12 7:47 ` Glauber Costa
2012-10-16 8:48 ` Kamezawa Hiroyuki
2012-10-08 10:06 ` [PATCH v4 11/14] memcg: allow a memcg with kmem charges to be destructed Glauber Costa
2012-10-08 10:06 ` [PATCH v4 12/14] execute the whole memcg freeing in free_worker Glauber Costa
2012-10-11 14:21 ` Michal Hocko
2012-10-08 10:06 ` [PATCH v4 13/14] protect architectures where THREAD_SIZE >= PAGE_SIZE against fork bombs Glauber Costa
2012-10-08 10:06 ` [PATCH v4 14/14] Add documentation about the kmem controller Glauber Costa
2012-10-11 14:35 ` Michal Hocko
2012-10-12 7:53 ` Glauber Costa
2012-10-12 8:44 ` Michal Hocko
2012-10-17 7:29 ` Kamezawa Hiroyuki
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=20121010112446.GE23011@dhcp22.suse.cz \
--to=mhocko@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=devel@openvz.org \
--cc=fweisbec@gmail.com \
--cc=glommer@parallels.com \
--cc=gthelen@google.com \
--cc=hannes@cmpxchg.org \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=suleiman@google.com \
--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;
as well as URLs for NNTP newsgroup(s).