lkml.org 
[lkml]   [2013]   [Apr]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC][PATCH 0/7] memcg: make memcg's life cycle the same as cgroup
    On Wed, Apr 03, 2013 at 05:11:15PM +0800, Li Zefan wrote:
    > (I'll be off from my office soon, and I won't be responsive in the following
    > 3 days.)
    >
    > I'm working on converting memcg to use cgroup->id, and then we can kill css_id.
    >
    > Now memcg has its own refcnt, so when a cgroup is destroyed, the memcg can
    > still be alive. This patchset converts memcg to always use css_get/put, so
    > memcg will have the same life cycle as its corresponding cgroup, and then
    > it's always safe for memcg to use cgroup->id.
    >
    > The historical reason that memcg didn't use css_get in some cases, is that
    > cgroup couldn't be removed if there're still css refs. The situation has
    > changed so that rmdir a cgroup will succeed regardless css refs, but won't
    > be freed until css refs goes down to 0.

    Hallelujah. This one is egregious if you take a step back and what
    happened as a whole. cgroup core had this weird object life-time
    management rule where it forces draining of all css refs on cgroup
    destruction, which is very unusual and puts unnecessary restrictions
    on css object usages in controllers.

    As the restriction wasn't too nice, memcg goes ahead and creates its
    own object which basically is the same as css but has a different
    life-time rule and does refcnting for both objects. Bah....

    So, yeah, let's please get rid of this abomination. It shouldn't have
    existed from the beginning.

    Thanks a lot for doing this!

    --
    tejun


    \
     
     \ /
      Last update: 2013-04-04 00:01    [W:5.183 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site