On 2014/6/21 5:01, Tejun Heo wrote: > Hello, Li. > > Sorry about the long delay. > > On Tue, Jun 10, 2014 at 10:58:45AM +0800, Li Zefan wrote: >> Yes, this is a long-standing issue. Besides the race you described, the child >> task's mems_allowed can be wrong if the cpuset's nodemask changes before the >> child has been added to the cgroup's tasklist. >> >> I remember Tejun once said he wanted to disallow task migration between >> cgroups during fork, and that should fix this problem. > > I'm having trouble remembering but yeah enforcing stricter behavior > across fork could be beneficial. Hmmm... the problem with making > forks exclusive against migrations is that we'll end up adding more > locking to the fork path which isn't too nice. > > Hmmm... other controllers (cgroup_freezer) can reliably synchronize > the child's state to the cgroup it belongs to. Why can't cpuset? Is > there something fundamentally missing in the cgroup API? > cgroup_freezer uses the fork callback. We can also do this for cpuset as suggested by David, which adds a little bit overhead to the fork path. David, care to send out a patch? >>> It needs to be slightly rewritten to work properly without negatively >>> impacting the latency of fork(). Do you have the cycles to do it? >>> >> >> Sounds you have other idea? > > I don't think the suggested patch breaks anything more than it was > broken before and we should probably apply it for the time being. Li? > Yeah, we should apply Gu Zheng's patch any way. -- 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>