Thread (28 messages) 28 messages, 2 authors, 2013-01-21

Re: [PATCH v2 3/7] memcg: provide online test for memcg

From: Glauber Costa <hidden>
Date: 2013-01-18 19:42:29
Also in: linux-mm

On 01/18/2013 07:56 AM, Michal Hocko wrote:
On Fri 18-01-13 16:37:15, Michal Hocko wrote:
quoted
On Fri 11-01-13 13:45:23, Glauber Costa wrote:
quoted
Since we are now splitting the memcg creation in two parts, following
the cgroup standard, it would be helpful to be able to determine if a
created memcg is already online.

We can do this by initially forcing the refcnt to 0, and waiting until
the last minute to flip it to 1.
Is this useful, though? What does it tell you? mem_cgroup_online can say
false even though half of the attributes have been already copied for
example. I think it should be vice versa. It should mark the point when
we _start_ copying values. mem_cgroup_online is not the best name then
of course. It depends what it is going to be used for...
And the later patch in the series shows that it is really not helpful on
its own. You need to rely on other lock to be helpful.
No, no need not.

The lock is there to protect the other fields, specially the outer
iterator. Not this in particular
This calls for
troubles and I do not think the win you get is really worth it. All it
gives you is basically that you can change an inheritable attribute
while your child is between css_alloc and css_online and so your
attribute change doesn't fail if the child creation fails between those
two. Is this the case you want to handle? Does it really even matter?
I think it matters a lot. Aside from the before vs after discussion to
which I've already conceded, without this protection we can't guarantee
that we won't end up with an inconsistent value of the tunables between
parent and child.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help