On Fri 29-05-15 10:07:37, Tejun Heo wrote: > Hello, > > On Fri, May 29, 2015 at 03:45:53PM +0200, Michal Hocko wrote: > > Sure but we are talking about processes here. They just happen to share > > mm. And this is exactly the behavior change I am talking about... With > > Are we talking about CLONE_VM w/o CLONE_THREAD? ie. two threadgroups > sharing the same VM? yes. > > the owner you could emulate "threads" with this patch you cannot > > anymore. IMO we shouldn't allow for that but just reading the original > > commit message (cf475ad28ac35) which has added mm->owner: > > " > > It also allows several control groups that are virtually grouped by > > mm_struct, to exist independent of the memory controller i.e., without > > adding mem_cgroup's for each controller, to mm_struct. > > " > > suggests it might have been intentional. That being said, I think it was > > I think he's talking about implmenting different controllers which may > want to add their own css pointer in mm_struct now wouldn't need to as > the mm is tagged with the owning task from which membership of all > controllers can be derived. I don't think that's something we need to > worry about. We haven't seen even a suggestion for such a controller > and even if that happens we'd be better off adding a separate field > for the new controller. Maybe I've just misunderstood. My understandig was that tasks sharing the mm could live in different cgroups while the memory would be bound by a shared memcg. > > a mistake back at the time and we should move on to a saner model. But I > > also believe we should be really vocal when the user visible behavior > > changes. If somebody really asks for the previous behavior I would > > insist on a _strong_ usecase. > > I'm a bit lost on what's cleared defined is actually changing. It's > not like userland had firm control over mm->owner. It was already a > crapshoot, no? 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. -- 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>