On Fri 29-05-15 11:23:28, Tejun Heo wrote: > Hello, > > On Fri, May 29, 2015 at 04:57:39PM +0200, Michal Hocko wrote: [...] > > OK so you creat a task A (leader) which clones several tasks Pn with > > CLONE_VM without CLONE_THREAD. Moving A around would control memcg > > membership while Pn could be moved around freely to control membership > > in other controllers (e.g. cpu to control shares). So it is something > > like moving threads separately. > > Sure, it'd behave clearly in certain cases but then again you'd have > cases where how mm->owner changes isn't clear at all when seen from > the userland. Sure. I am definitely _not_ advocating this use case! As said before, I consider it abuse. It is just fair to point out this is a user visible change IMO. > e.g. When the original owner goes away, the assignment > of the next owner is essentially arbitrary. That's what I meant by > saying it was already a crapshoot. We should definitely document the > change but this isn't likely to be an issue. CLONE_VM && > !CLONE_THREAD is an extreme corner case to begin with and even the > behavior there wasn't all that clearly defined. That is the line of argumentation in my changelog ;) -- Michal Hocko SUSE Labs -- 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>