From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756148AbbE2OHv (ORCPT ); Fri, 29 May 2015 10:07:51 -0400 Received: from mail-qk0-f175.google.com ([209.85.220.175]:34631 "EHLO mail-qk0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752978AbbE2OHn (ORCPT ); Fri, 29 May 2015 10:07:43 -0400 Date: Fri, 29 May 2015 10:07:37 -0400 From: Tejun Heo To: Michal Hocko Cc: Johannes Weiner , linux-mm@kvack.org, Oleg Nesterov , Vladimir Davydov , KAMEZAWA Hiroyuki , KOSAKI Motohiro , Andrew Morton , LKML Subject: Re: [RFC 3/3] memcg: get rid of mm_struct::owner Message-ID: <20150529140737.GK27479@htj.duckdns.org> References: <1432641006-8025-1-git-send-email-mhocko@suse.cz> <1432641006-8025-4-git-send-email-mhocko@suse.cz> <20150526141011.GA11065@cmpxchg.org> <20150528210742.GF27479@htj.duckdns.org> <20150529120838.GC22728@dhcp22.suse.cz> <20150529131055.GH27479@htj.duckdns.org> <20150529134553.GD22728@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150529134553.GD22728@dhcp22.suse.cz> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? > 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. > 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? Thanks. -- tejun