All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Weiner <hannes@cmpxchg.org>
To: Michal Hocko <mhocko@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-mm@kvack.org
Subject: Re: [PATCH -v2 2/6] memcg: cleanup charge routines
Date: Tue, 4 Feb 2014 14:36:11 -0500	[thread overview]
Message-ID: <20140204193611.GS6963@cmpxchg.org> (raw)
In-Reply-To: <20140204191125.GA26000@dhcp22.suse.cz>

On Tue, Feb 04, 2014 at 08:11:25PM +0100, Michal Hocko wrote:
> On Tue 04-02-14 11:40:50, Johannes Weiner wrote:
> > On Tue, Feb 04, 2014 at 05:12:30PM +0100, Michal Hocko wrote:
> > > On Tue 04-02-14 11:05:09, Johannes Weiner wrote:
> > > > On Tue, Feb 04, 2014 at 02:28:56PM +0100, Michal Hocko wrote:
> > > > > -	/*
> > > > > -	 * We always charge the cgroup the mm_struct belongs to.
> > > > > -	 * The mm_struct's mem_cgroup changes on task migration if the
> > > > > -	 * thread group leader migrates. It's possible that mm is not
> > > > > -	 * set, if so charge the root memcg (happens for pagecache usage).
> > > > > -	 */
> > > > > -	if (!*ptr && !mm)
> > > > > -		*ptr = root_mem_cgroup;
> > > > 
> > > > [...]
> > > > 
> > > > >  /*
> > > > > + * Charges and returns memcg associated with the given mm (or root_mem_cgroup
> > > > > + * if mm is NULL). Returns NULL if memcg is under OOM.
> > > > > + */
> > > > > +static struct mem_cgroup *mem_cgroup_try_charge_mm(struct mm_struct *mm,
> > > > > +				   gfp_t gfp_mask,
> > > > > +				   unsigned int nr_pages,
> > > > > +				   bool oom)
> > > > > +{
> > > > > +	struct mem_cgroup *memcg;
> > > > > +	int ret;
> > > > > +
> > > > > +	/*
> > > > > +	 * We always charge the cgroup the mm_struct belongs to.
> > > > > +	 * The mm_struct's mem_cgroup changes on task migration if the
> > > > > +	 * thread group leader migrates. It's possible that mm is not
> > > > > +	 * set, if so charge the root memcg (happens for pagecache usage).
> > > > > +	 */
> > > > > +	if (!mm)
> > > > > +		goto bypass;
> > > > 
> > > > Why shuffle it around right before you remove it anyway?  Just start
> > > > the series off with the patches that delete stuff without having to
> > > > restructure anything, get those out of the way.
> > > 
> > > As mentioned in the previous email. I wanted to have this condition
> > > removal bisectable. So it is removed in the next patch when it is
> > > replaced by VM_BUG_ON.
> > 
> > I'm not suggesting to sneak the removal into *this* patch,
> 
> OK
> 
> > just put the simple stand-alone patches that remove stuff first in the
> > series.
> 
> In this particular case, though, the reduced condition is much easier
> to review IMO. Just look at the jungle of different *ptr vs. mm
> combinations described in this patch description which would have to be
> reviewed separately if I moved the removal before this patch.
> The ptr part of the original condition went away naturally here while
> the reasoning why there is no code path implicitly relying on (!ptr &&
> !mm) resulting in bypass would be harder.

You just have to check ptr=NULL callsites...?  "Callsites that don't
provide their own memcg pass a valid mm pointer for lookup."

Anyway, I'm just telling you what threw me off during review.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Johannes Weiner <hannes@cmpxchg.org>
To: Michal Hocko <mhocko@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-mm@kvack.org
Subject: Re: [PATCH -v2 2/6] memcg: cleanup charge routines
Date: Tue, 4 Feb 2014 14:36:11 -0500	[thread overview]
Message-ID: <20140204193611.GS6963@cmpxchg.org> (raw)
In-Reply-To: <20140204191125.GA26000@dhcp22.suse.cz>

On Tue, Feb 04, 2014 at 08:11:25PM +0100, Michal Hocko wrote:
> On Tue 04-02-14 11:40:50, Johannes Weiner wrote:
> > On Tue, Feb 04, 2014 at 05:12:30PM +0100, Michal Hocko wrote:
> > > On Tue 04-02-14 11:05:09, Johannes Weiner wrote:
> > > > On Tue, Feb 04, 2014 at 02:28:56PM +0100, Michal Hocko wrote:
> > > > > -	/*
> > > > > -	 * We always charge the cgroup the mm_struct belongs to.
> > > > > -	 * The mm_struct's mem_cgroup changes on task migration if the
> > > > > -	 * thread group leader migrates. It's possible that mm is not
> > > > > -	 * set, if so charge the root memcg (happens for pagecache usage).
> > > > > -	 */
> > > > > -	if (!*ptr && !mm)
> > > > > -		*ptr = root_mem_cgroup;
> > > > 
> > > > [...]
> > > > 
> > > > >  /*
> > > > > + * Charges and returns memcg associated with the given mm (or root_mem_cgroup
> > > > > + * if mm is NULL). Returns NULL if memcg is under OOM.
> > > > > + */
> > > > > +static struct mem_cgroup *mem_cgroup_try_charge_mm(struct mm_struct *mm,
> > > > > +				   gfp_t gfp_mask,
> > > > > +				   unsigned int nr_pages,
> > > > > +				   bool oom)
> > > > > +{
> > > > > +	struct mem_cgroup *memcg;
> > > > > +	int ret;
> > > > > +
> > > > > +	/*
> > > > > +	 * We always charge the cgroup the mm_struct belongs to.
> > > > > +	 * The mm_struct's mem_cgroup changes on task migration if the
> > > > > +	 * thread group leader migrates. It's possible that mm is not
> > > > > +	 * set, if so charge the root memcg (happens for pagecache usage).
> > > > > +	 */
> > > > > +	if (!mm)
> > > > > +		goto bypass;
> > > > 
> > > > Why shuffle it around right before you remove it anyway?  Just start
> > > > the series off with the patches that delete stuff without having to
> > > > restructure anything, get those out of the way.
> > > 
> > > As mentioned in the previous email. I wanted to have this condition
> > > removal bisectable. So it is removed in the next patch when it is
> > > replaced by VM_BUG_ON.
> > 
> > I'm not suggesting to sneak the removal into *this* patch,
> 
> OK
> 
> > just put the simple stand-alone patches that remove stuff first in the
> > series.
> 
> In this particular case, though, the reduced condition is much easier
> to review IMO. Just look at the jungle of different *ptr vs. mm
> combinations described in this patch description which would have to be
> reviewed separately if I moved the removal before this patch.
> The ptr part of the original condition went away naturally here while
> the reasoning why there is no code path implicitly relying on (!ptr &&
> !mm) resulting in bypass would be harder.

You just have to check ptr=NULL callsites...?  "Callsites that don't
provide their own memcg pass a valid mm pointer for lookup."

Anyway, I'm just telling you what threw me off during review.

  reply	other threads:[~2014-02-04 19:36 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-04 13:28 [PATCH -v2 0/6] memcg: some charge path cleanups + css offline vs. charge race fix Michal Hocko
2014-02-04 13:28 ` Michal Hocko
2014-02-04 13:28 ` [PATCH -v2 1/6] memcg: do not replicate try_get_mem_cgroup_from_mm in __mem_cgroup_try_charge Michal Hocko
2014-02-04 13:28   ` Michal Hocko
2014-02-04 15:55   ` Johannes Weiner
2014-02-04 15:55     ` Johannes Weiner
2014-02-04 16:05     ` Michal Hocko
2014-02-04 16:05       ` Michal Hocko
2014-02-05 13:49       ` Michal Hocko
2014-02-05 13:49         ` Michal Hocko
2014-02-04 13:28 ` [PATCH -v2 2/6] memcg: cleanup charge routines Michal Hocko
2014-02-04 13:28   ` Michal Hocko
2014-02-04 16:05   ` Johannes Weiner
2014-02-04 16:05     ` Johannes Weiner
2014-02-04 16:12     ` Michal Hocko
2014-02-04 16:12       ` Michal Hocko
2014-02-04 16:40       ` Johannes Weiner
2014-02-04 16:40         ` Johannes Weiner
2014-02-04 19:11         ` Michal Hocko
2014-02-04 19:11           ` Michal Hocko
2014-02-04 19:36           ` Johannes Weiner [this message]
2014-02-04 19:36             ` Johannes Weiner
2014-02-04 13:28 ` [PATCH -v2 3/6] memcg: mm == NULL is not allowed for mem_cgroup_try_charge_mm Michal Hocko
2014-02-04 13:28   ` Michal Hocko
2014-02-04 16:05   ` Johannes Weiner
2014-02-04 16:05     ` Johannes Weiner
2014-02-04 13:28 ` [PATCH -v2 4/6] memcg: make sure that memcg is not offline when charging Michal Hocko
2014-02-04 13:28   ` Michal Hocko
2014-02-04 16:29   ` Johannes Weiner
2014-02-04 16:29     ` Johannes Weiner
2014-02-05 13:38     ` Michal Hocko
2014-02-05 13:38       ` Michal Hocko
2014-02-05 15:28       ` Johannes Weiner
2014-02-05 15:28         ` Johannes Weiner
2014-02-05 15:42         ` Tejun Heo
2014-02-05 15:42           ` Tejun Heo
2014-02-05 16:19         ` Michal Hocko
2014-02-05 16:19           ` Michal Hocko
2014-02-05 16:29           ` Michal Hocko
2014-02-05 16:29             ` Michal Hocko
2014-02-05 16:30           ` Tejun Heo
2014-02-05 16:30             ` Tejun Heo
2014-02-05 16:45           ` Johannes Weiner
2014-02-05 16:45             ` Johannes Weiner
2014-02-05 17:23             ` Michal Hocko
2014-02-05 17:23               ` Michal Hocko
2014-02-04 13:28 ` [PATCH -v2 5/6] memcg, kmem: clean up memcg parameter handling Michal Hocko
2014-02-04 13:28   ` Michal Hocko
2014-02-04 16:32   ` Johannes Weiner
2014-02-04 16:32     ` Johannes Weiner
2014-02-04 16:42     ` Michal Hocko
2014-02-04 16:42       ` Michal Hocko
2014-02-04 13:29 ` [PATCH -v2 6/6] Revert "mm: memcg: fix race condition between memcg teardown and swapin" Michal Hocko
2014-02-04 13:29   ` 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=20140204193611.GS6963@cmpxchg.org \
    --to=hannes@cmpxchg.org \
    --cc=akpm@linux-foundation.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=mhocko@suse.cz \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.