From: Johannes Weiner <hannes@cmpxchg.org>
To: David Rientjes <rientjes@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Michal Hocko <mhocko@suse.cz>,
linux-mm@kvack.org, cgroups@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [patch] mm: memcg: do not declare OOM from __GFP_NOFAIL allocations
Date: Wed, 27 Nov 2013 11:39:16 -0500 [thread overview]
Message-ID: <20131127163916.GB3556@cmpxchg.org> (raw)
In-Reply-To: <alpine.DEB.2.02.1311261931210.5973@chino.kir.corp.google.com>
On Tue, Nov 26, 2013 at 07:33:12PM -0800, David Rientjes wrote:
> On Tue, 26 Nov 2013, David Rientjes wrote:
>
> > On Fri, 22 Nov 2013, Johannes Weiner wrote:
> >
> > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> > > index 13b9d0f..cc4f9cb 100644
> > > --- a/mm/memcontrol.c
> > > +++ b/mm/memcontrol.c
> > > @@ -2677,6 +2677,9 @@ static int __mem_cgroup_try_charge(struct mm_struct *mm,
> > > if (unlikely(task_in_memcg_oom(current)))
> > > goto bypass;
> > >
> > > + if (gfp_mask & __GFP_NOFAIL)
> > > + oom = false;
> > > +
> > > /*
> > > * We always charge the cgroup the mm_struct belongs to.
> > > * The mm_struct's mem_cgroup changes on task migration if the
> >
> > Sorry, I don't understand this. What happens in the following scenario:
> >
> > - memory.usage_in_bytes == memory.limit_in_bytes,
> >
> > - memcg reclaim fails to reclaim memory, and
> >
> > - all processes (perhaps only one) attached to the memcg are doing one of
> > the over dozen __GFP_NOFAIL allocations in the kernel?
> >
> > How do we make forward progress if you cannot oom kill something?
Bypass the limit.
> Ah, this is because of 3168ecbe1c04 ("mm: memcg: use proper memcg in limit
> bypass") which just bypasses all of these allocations and charges the root
> memcg. So if allocations want to bypass memcg isolation they just have to
> be __GFP_NOFAIL?
I don't think we have another option.
next prev parent reply other threads:[~2013-11-27 16:39 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-22 17:17 [patch] mm: memcg: do not declare OOM from __GFP_NOFAIL allocations Johannes Weiner
2013-11-27 1:01 ` David Rientjes
2013-11-27 3:33 ` David Rientjes
2013-11-27 16:39 ` Johannes Weiner [this message]
2013-11-27 21:38 ` David Rientjes
2013-11-27 22:53 ` Johannes Weiner
2013-11-27 23:34 ` David Rientjes
2013-11-28 10:20 ` Michal Hocko
2013-11-29 23:46 ` David Rientjes
2013-12-02 13:22 ` Michal Hocko
2013-12-02 23:02 ` David Rientjes
2013-12-03 22:25 ` Johannes Weiner
2013-12-03 23:40 ` David Rientjes
2013-12-04 3:01 ` Johannes Weiner
2013-12-04 4:34 ` Dave Chinner
2013-12-04 5:25 ` Johannes Weiner
2013-12-04 6:10 ` David Rientjes
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=20131127163916.GB3556@cmpxchg.org \
--to=hannes@cmpxchg.org \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.cz \
--cc=rientjes@google.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;
as well as URLs for NNTP newsgroup(s).