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 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>