From: David Rientjes <rientjes@google.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Mel Gorman <mgorman@suse.de>, Michal Hocko <mhocko@suse.cz>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [patch] mm, page_alloc: make __GFP_NOFAIL really not fail
Date: Tue, 10 Dec 2013 16:11:40 -0800 (PST) [thread overview]
Message-ID: <alpine.DEB.2.02.1312101559590.22701@chino.kir.corp.google.com> (raw)
In-Reply-To: <20131210153909.8b4bfa1d643e5f8582eff7c9@linux-foundation.org>
On Tue, 10 Dec 2013, Andrew Morton wrote:
> > Heh, it's difficult to remove __GFP_NOFAIL when new users get added:
> > 84235de394d9 ("fs: buffer: move allocation failure loop into the
> > allocator") added a new user
>
> That wasn't reeeeealy a new user - it was "convert an existing
> open-coded retry-for-ever loop". Which is what __GFP_NOFAIL is for.
>
No, it just looks like that's what it did. find_or_create_page() in that
function does an order-0 allocation which always implicitly __GFP_NOFAIL
because of the should_alloc_retry() behavior. So why does it need to add
__GFP_NOFAIL there now? Because it is now allowed to bypass memcg limits
to the root memcg, which is new behavior with the patch. It adds
additional memcg powers that can't be duplicated in the caller, so now
it's really become __GFP_BYPASS_MEMCG_LIMIT_ON_OOM for everything that was
doing order-3 or smaller allocations, which should be all existing
__GFP_NOFAIL users.
--
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>
next prev parent reply other threads:[~2013-12-11 0:11 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-09 21:56 David Rientjes
2013-12-09 23:22 ` Andrew Morton
2013-12-10 23:20 ` David Rientjes
2013-12-10 23:39 ` Andrew Morton
2013-12-11 0:11 ` David Rientjes [this message]
2013-12-12 1:07 ` Dave Chinner
2013-12-11 0:19 ` [patch alternative] mm, page_alloc: warn for non-blockable __GFP_NOFAIL allocation failure David Rientjes
2013-12-11 0:26 ` [patch] checkpatch: add warning of future __GFP_NOFAIL use David Rientjes
2013-12-11 1:35 ` Joe Perches
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=alpine.DEB.2.02.1312101559590.22701@chino.kir.corp.google.com \
--to=rientjes@google.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox