Hello, Eric. On Fri, Jun 01, 2018 at 09:53:09AM -0500, Eric W. Biederman wrote: > > From a userspace perspective the cgroup of a mm is determined by which > the cgroup the task belongs too. As practically an mm can only belong to > a single memory cgroup having multiple tasks with the same mm in different > memory cgroups is not well defined. > > Avoid the difficulties of dealing with crazy semantics and restrict all > tasks that share a single mm to the same memory cgroup. > > This is accomplished by adding a new function mem_cgroup_mm_can_attach > that checks this condition with a straight forward algorithm. In the worst > case it is O(N^2). In the common case it should be O(N) in the number of > tasks being migrated. As typically only a single process and thus a single > process is being migrated and it is optimized for that case. > > There are users of mmget such as proc that can create references to an > mm this function can not find. This results in an unnecessary > migration failure. It does not break the invariant that every task of > an mm stays in the same memory cgroup. So this condition is annoying > but harmelss. > > This requires multi-threaded mm's to be migrated using the procs file. > > This effectively forbids process with mm's shared processes being migrated. > Although enabling the control file might work.
So, I don't think we need to support putting tasks which share a mm in different cgroups. That said, if we're gonna put in that restriction, I think it should be in cgroup core rather than memcg can_attach. The only thing we'd need to do is widening what cgroup migration considers to be a process. Thanks. -- tejun
