lkml.org 
[lkml]   [2015]   [May]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC 3/3] memcg: get rid of mm_struct::owner
Hello, Johannes, Michal.

On Tue, May 26, 2015 at 10:10:11AM -0400, Johannes Weiner wrote:
> On Tue, May 26, 2015 at 01:50:06PM +0200, Michal Hocko wrote:
> > Please note that this patch introduces a USER VISIBLE CHANGE OF BEHAVIOR.
> > Without mm->owner _all_ tasks associated with the mm_struct would
> > initiate memcg migration while previously only owner of the mm_struct
> > could do that. The original behavior was awkward though because the user
> > task didn't have any means to find out the current owner (esp. after
> > mm_update_next_owner) so the migration behavior was not well defined
> > in general.
> > New cgroup API (unified hierarchy) will discontinue tasks file which
> > means that migrating threads will no longer be possible. In such a case
> > having CLONE_VM without CLONE_THREAD could emulate the thread behavior
> > but this patch prevents from isolating memcg controllers from others.
> > Nevertheless I am not convinced such a use case would really deserve
> > complications on the memcg code side.
>
> I think such a change is okay. The memcg semantics of moving threads
> with the same mm into separate groups have always been arbitrary. No
> reasonable behavior can be expected of this, so what sane real life
> usecase would rely on it?

I suppose that making mm always follow the threadgroup leader should
be fine, right? While this wouldn't make any difference in the
unified hierarchy, I think this would make more sense for traditional
hierarchies.

Thanks.

--
tejun


\
 
 \ /
  Last update: 2015-05-28 23:21    [W:0.261 / U:0.168 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site