public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.cz>
To: Tejun Heo <tj@kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
	linux-mm@kvack.org, Oleg Nesterov <oleg@redhat.com>,
	Vladimir Davydov <vdavydov@parallels.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC 3/3] memcg: get rid of mm_struct::owner
Date: Fri, 29 May 2015 15:45:53 +0200	[thread overview]
Message-ID: <20150529134553.GD22728@dhcp22.suse.cz> (raw)
In-Reply-To: <20150529131055.GH27479@htj.duckdns.org>

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

  reply	other threads:[~2015-05-29 13:46 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-26 11:50 [RFC 0/3] get rid of mm_struct::owner Michal Hocko
2015-05-26 11:50 ` [RFC 1/3] memcg: restructure mem_cgroup_can_attach() Michal Hocko
2015-05-26 11:50 ` [RFC 2/3] memcg: Use mc.moving_task as the indication for charge moving Michal Hocko
2015-05-26 11:50 ` [RFC 3/3] memcg: get rid of mm_struct::owner Michal Hocko
2015-05-26 14:10   ` Johannes Weiner
2015-05-26 15:11     ` Michal Hocko
2015-05-26 17:20       ` Johannes Weiner
2015-05-27 14:48         ` Michal Hocko
2015-05-28 21:07     ` Tejun Heo
2015-05-29 12:08       ` Michal Hocko
2015-05-29 13:10         ` Tejun Heo
2015-05-29 13:45           ` Michal Hocko [this message]
2015-05-29 14:07             ` Tejun Heo
2015-05-29 14:57               ` Michal Hocko
2015-05-29 15:23                 ` Tejun Heo
2015-05-29 15:26                   ` Michal Hocko
2015-05-26 16:36   ` Oleg Nesterov
2015-05-26 17:22     ` Michal Hocko
2015-05-26 17:38       ` Oleg Nesterov
2015-05-27  9:43         ` Michal Hocko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150529134553.GD22728@dhcp22.suse.cz \
    --to=mhocko@suse.cz \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=oleg@redhat.com \
    --cc=tj@kernel.org \
    --cc=vdavydov@parallels.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox