On Fri 29-05-15 09:10:55, Tejun Heo wrote: > On Fri, May 29, 2015 at 02:08:38PM +0200, Michal Hocko wrote: > > > I suppose that making mm always follow the threadgroup leader should > > > be fine, right? > > > > That is the plan. > > Cool. > > > > While this wouldn't make any difference in the unified hierarchy, > > > > Just to make sure I understand. "wouldn't make any difference" because > > the API is not backward compatible right? > > Hmm... because it's always per-process. If any thread is going, the > whole process is going together. 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 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 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. -- 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>