From mboxrd@z Thu Jan 1 00:00:00 1970 From: Glauber Costa Subject: Re: [PATCH 0/4] replace cgroup_lock with local lock in memcg Date: Fri, 30 Nov 2012 19:59:21 +0400 Message-ID: <50B8D7D9.9010800@parallels.com> References: <1354282286-32278-1-git-send-email-glommer@parallels.com> <20121130155228.GE3873@htj.dyndns.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20121130155228.GE3873@htj.dyndns.org> Sender: owner-linux-mm@kvack.org List-ID: Content-Type: text/plain; charset="us-ascii" To: Tejun Heo Cc: cgroups@vger.kernel.org, linux-mm@kvack.org, kamezawa.hiroyu@jp.fujitsu.com, Johannes Weiner , Michal Hocko On 11/30/2012 07:52 PM, Tejun Heo wrote: > Hey, Glauber. > > I don't know enough about memcg to be acking this but overall it looks > pretty good to me. > > On Fri, Nov 30, 2012 at 05:31:22PM +0400, Glauber Costa wrote: >> For the problem of attaching tasks, I am using something similar to cpusets: >> when task attaching starts, we will flip a flag "attach_in_progress", that will >> be flipped down when it finishes. This way, all readers can know that a task is >> joining the group and take action accordingly. With this, we can guarantee that >> the behavior of move_charge_at_immigrate continues safe > > Yeap, attach_in_progress is useful if there are some conditions which > shouldn't change between ->can_attach() and ->attach(). With the > immigrate thing gone, this no longer is necessary, right? > Yes and no. While it can help with immigrate, we still have kmem that needs to be protected against tasks joining. However, kmem is easier. If attach_in_progress is ever positive, it means that a task is joining, and it is already unacceptable for kmem - so we can fail right away. -- 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: email@kvack.org