From: Michal Hocko <mhocko@kernel.org>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: akpm@linux-foundation.org, hannes@cmpxchg.org,
rientjes@google.com, mgorman@suse.de, hillf.zj@alibaba-inc.com,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/3 -v3] GFP_NOFAIL cleanups
Date: Thu, 5 Jan 2017 12:54:18 +0100 [thread overview]
Message-ID: <20170105115418.GN21618@dhcp22.suse.cz> (raw)
In-Reply-To: <201701051950.EAB48947.FFVSHOOQMJtLFO@I-love.SAKURA.ne.jp>
On Thu 05-01-17 19:50:23, Tetsuo Handa wrote:
[...]
> Anyway, I suggest merging description update shown below into this series and
> getting confirmation from all existing __GFP_NOFAIL users. If all existing
> __GFP_NOFAIL users are OK with this series (in other words, informed the risk
> caused by this series), I'm also OK with this series.
>
> --- a/include/linux/gfp.h
> +++ b/include/linux/gfp.h
> @@ -135,16 +135,24 @@
> * __GFP_REPEAT: Try hard to allocate the memory, but the allocation attempt
> * _might_ fail. This depends upon the particular VM implementation.
> *
> - * __GFP_NOFAIL: The VM implementation _must_ retry infinitely: the caller
> - * cannot handle allocation failures. New users should be evaluated carefully
> - * (and the flag should be used only when there is no reasonable failure
> - * policy) but it is definitely preferable to use the flag rather than
> - * opencode endless loop around allocator.
> - *
> - * __GFP_NORETRY: The VM implementation must not retry indefinitely and will
> - * return NULL when direct reclaim and memory compaction have failed to allow
> - * the allocation to succeed. The OOM killer is not called with the current
> - * implementation.
> + * __GFP_NOFAIL: The VM implementation must not give up even after direct
> + * reclaim and memory compaction have failed to allow the allocation to
> + * succeed. Note that since the OOM killer is not called with the current
> + * implementation when direct reclaim and memory compaction have failed to
> + * allow the allocation to succeed unless __GFP_FS is also used (and some
> + * other conditions are met), e.g. GFP_NOFS | __GFP_NOFAIL allocation has
> + * possibility of lockup. To reduce the possibility of lockup, __GFP_HIGH is
> + * implicitly granted by the current implementation if __GFP_NOFAIL is used.
> + * New users of __GFP_NOFAIL should be evaluated carefully (and __GFP_NOFAIL
> + * should be used only when there is no reasonable failure policy) but it is
> + * definitely preferable to use __GFP_NOFAIL rather than opencode endless
> + * loop around allocator, for a stall detection check inside allocator will
> + * likely be able to emit possible lockup warnings unless __GFP_NOWARN is
> + * also used.
This is both wrong and unnecessarily describing implementation details.
Non-failing allocation which must not give up can lockup pretty much by
definition. IMHO the current description is sufficient.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2017-01-05 11:54 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-20 13:49 [PATCH 0/3 -v3] GFP_NOFAIL cleanups Michal Hocko
2016-12-20 13:49 ` [PATCH 1/3] mm: consolidate GFP_NOFAIL checks in the allocator slowpath Michal Hocko
2016-12-20 13:49 ` [PATCH 2/3] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically Michal Hocko
2016-12-20 15:31 ` Tetsuo Handa
2016-12-21 8:15 ` Michal Hocko
2017-01-19 18:41 ` Johannes Weiner
2017-01-20 8:33 ` Hillf Danton
2017-01-24 12:40 ` Michal Hocko
2017-01-25 7:00 ` Hillf Danton
2017-01-25 7:59 ` Michal Hocko
2017-01-25 8:41 ` Hillf Danton
2017-01-25 10:19 ` Michal Hocko
2016-12-20 13:49 ` [PATCH 3/3] mm: help __GFP_NOFAIL allocations which do not trigger OOM killer Michal Hocko
2017-01-02 15:49 ` [PATCH 0/3 -v3] GFP_NOFAIL cleanups Michal Hocko
2017-01-03 1:36 ` Tetsuo Handa
2017-01-03 8:42 ` Michal Hocko
2017-01-03 14:38 ` Tetsuo Handa
2017-01-03 16:25 ` Vlastimil Babka
2017-01-03 20:40 ` Michal Hocko
2017-01-04 14:22 ` Tetsuo Handa
2017-01-04 15:20 ` Michal Hocko
2017-01-05 10:50 ` Tetsuo Handa
2017-01-05 11:54 ` Michal Hocko [this message]
2017-01-18 18:42 ` 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=20170105115418.GN21618@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=hillf.zj@alibaba-inc.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
--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).