linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Weiner <hannes@cmpxchg.org>
To: Michal Hocko <mhocko@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Hugh Dickins <hughd@google.com>, Tejun Heo <tj@kernel.org>,
	Vladimir Davydov <vdavydov@parallels.com>,
	cgroups@vger.kernel.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [patch 03/12] mm: huge_memory: use GFP_TRANSHUGE when charging huge pages
Date: Wed, 18 Jun 2014 16:26:17 -0400	[thread overview]
Message-ID: <20140618202617.GE7331@cmpxchg.org> (raw)
In-Reply-To: <20140617162747.GB9572@dhcp22.suse.cz>

On Tue, Jun 17, 2014 at 06:27:47PM +0200, Michal Hocko wrote:
> On Tue 17-06-14 11:38:14, Johannes Weiner wrote:
> > On Tue, Jun 17, 2014 at 04:23:17PM +0200, Michal Hocko wrote:
> [...]
> > > @@ -2647,7 +2645,7 @@ retry:
> > >  	if (fatal_signal_pending(current))
> > >  		goto bypass;
> > >  
> > > -	if (!oom)
> > > +	if (!oom_gfp_allowed(gfp_mask))
> > >  		goto nomem;
> > 
> > We don't actually need that check: if __GFP_NORETRY is set, we goto
> > nomem directly after reclaim fails and don't even reach here.
> 
> I meant it for further robustness. If we ever change oom_gfp_allowed in
> future and have new and unexpected users then we should back off.  Or
> maybe WARN_ON(!oom_gfp_allowed(gfp_mask)) would be more appropriate to
> catch those and fix the charging code or the charger?

There is a slight deviation from the page allocator in that we could
potentially invoke OOM on NOFS charges, but I'm not sure whether NOFS
flags are wrong to enter the memcg charge code, per se, so the WARN_ON
would appear like a fairly random restriction to have...

> > From eda800d2aa2376d347d6d4f7660e3450bd4c5dbb Mon Sep 17 00:00:00 2001
> > From: Michal Hocko <mhocko@suse.cz>
> > Date: Tue, 17 Jun 2014 11:10:59 -0400
> > Subject: [patch] mm: memcontrol: remove explicit OOM parameter in charge path
> > 
> > For the page allocator, __GFP_NORETRY implies that no OOM should be
> > triggered, whereas memcg has an explicit parameter to disable OOM.
> > 
> > The only callsites that want OOM disabled are THP charges and charge
> > moving.  THP already uses __GFP_NORETRY and charge moving can use it
> > as well - one full reclaim cycle should be plenty.  Switch it over,
> > then remove the OOM parameter.
> > 
> > Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
> 
> Signed-off-by: Michal Hocko <mhocko@suse.cz>

Thanks!

--
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>

  reply	other threads:[~2014-06-18 20:26 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-16 19:54 [patch 00/12] mm: memcontrol: naturalize charge lifetime v3 Johannes Weiner
2014-06-16 19:54 ` [patch 01/12] mm: memcontrol: fold mem_cgroup_do_charge() Johannes Weiner
2014-06-16 19:54 ` [patch 02/12] mm: memcontrol: rearrange charging fast path Johannes Weiner
2014-06-16 19:54 ` [patch 03/12] mm: huge_memory: use GFP_TRANSHUGE when charging huge pages Johannes Weiner
2014-06-17 13:47   ` Michal Hocko
2014-06-17 15:30     ` Johannes Weiner
2014-06-17 16:20       ` Michal Hocko
2014-06-17 14:23   ` Michal Hocko
2014-06-17 15:38     ` Johannes Weiner
2014-06-17 16:27       ` Michal Hocko
2014-06-18 20:26         ` Johannes Weiner [this message]
2014-06-16 19:54 ` [patch 04/12] mm: memcontrol: retry reclaim for oom-disabled and __GFP_NOFAIL charges Johannes Weiner
2014-06-17 13:53   ` Michal Hocko
2014-06-17 15:45     ` Johannes Weiner
2014-06-17 16:30       ` Michal Hocko
2014-06-16 19:54 ` [patch 05/12] mm: memcontrol: reclaim at least once for __GFP_NORETRY Johannes Weiner
2014-06-16 19:54 ` [patch 06/12] mm: memcontrol: simplify move precharge function Johannes Weiner
2014-06-17 14:59   ` Michal Hocko
2014-06-16 19:54 ` [patch 07/12] mm: memcontrol: catch root bypass in move precharge Johannes Weiner
2014-06-16 19:54 ` [patch 08/12] mm: memcontrol: use root_mem_cgroup res_counter Johannes Weiner
2014-06-16 19:54 ` [patch 09/12] mm: memcontrol: remove ordering between pc->mem_cgroup and PageCgroupUsed Johannes Weiner
2014-06-16 19:54 ` [patch 10/12] mm: memcontrol: do not acquire page_cgroup lock for kmem pages Johannes Weiner
2014-06-16 19:54 ` [patch 11/12] mm: memcontrol: rewrite charge API Johannes Weiner
2014-06-16 19:54 ` [patch 12/12] mm: memcontrol: rewrite uncharge API Johannes Weiner
2014-06-17 16:36 ` [patch 00/12] mm: memcontrol: naturalize charge lifetime v3 Michal Hocko
2014-06-18 20:31   ` Johannes Weiner
2014-06-18 20:36     ` Andrew Morton
2014-06-18 21:02       ` 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=20140618202617.GE7331@cmpxchg.org \
    --to=hannes@cmpxchg.org \
    --cc=akpm@linux-foundation.org \
    --cc=cgroups@vger.kernel.org \
    --cc=hughd@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.cz \
    --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