LKML Archive on lore.kernel.org
 help / color / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Andrew Morton <akpm@linux-foundation.org>,
	Vlastimil Babka <vbabka@suse.cz>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
	Mel Gorman <mgorman@suse.de>, NeilBrown <neilb@suse.com>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-mm@kvack.org
Subject: Re: [PATCH 2/6] mm, tree wide: replace __GFP_REPEAT by __GFP_RETRY_MAYFAIL with more useful semantic
Date: Mon, 26 Jun 2017 14:42:34 +0200
Message-ID: <20170626124233.GN11534@dhcp22.suse.cz> (raw)
In-Reply-To: <20170626123847.GM11534@dhcp22.suse.cz>

On Mon 26-06-17 14:38:47, Michal Hocko wrote:
> On Mon 26-06-17 14:17:30, Vlastimil Babka wrote:
> > On 06/26/2017 02:14 PM, Michal Hocko wrote:
> > > On Mon 26-06-17 13:45:19, Vlastimil Babka wrote:
> > >> On 06/23/2017 10:53 AM, Michal Hocko wrote:
> > > [...]
> > >>> - GFP_KERNEL - both background and direct reclaim are allowed and the
> > >>>   _default_ page allocator behavior is used. That means that !costly
> > >>>   allocation requests are basically nofail (unless the requesting task
> > >>>   is killed by the OOM killer)
> > >>
> > >> Should we explicitly point out that failure must be handled? After lots
> > >> of talking about "too small to fail", people might get the wrong impression.
> > > 
> > > OK. What about the following.
> > > "That means that !costly allocation requests are basically nofail but
> > > there is no guarantee of thaat behavior so failures have to be checked
> > 
> >                            that
> > 
> > > properly by callers (e.g. OOM killer victim is allowed to fail
> > > currently).
> > 
> > Looks good, thanks!
> 
> Andrew, could you fold the following in and replace the GFP_KERNEL part
> of the changelog with the updated text. Thanks!

Forgot to address other thing spotted by Vlastimil.
---
>From c7f9dba93ac3001fbafe287729c4e2bb646b25f4 Mon Sep 17 00:00:00 2001
From: Michal Hocko <mhocko@suse.com>
Date: Mon, 26 Jun 2017 14:31:19 +0200
Subject: [PATCH] 
 mm-tree-wide-replace-__gfp_repeat-by-__gfp_retry_mayfail-with-more-useful-semantic-fix.patch

- GFP_KERNEL - both background and direct reclaim are allowed and the
  _default_ page allocator behavior is used. That means that !costly
  allocation requests are basically nofail but there is no guarantee
  of that behavior so failures have to be checked properly by callers
  (e.g. OOM killer victim is allowed to fail currently).

Signed-off-by: Michal Hocko <mhocko@suse.com>
---
 include/linux/gfp.h | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index 6be1f836b69e..bcfb9f7c46f5 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -25,7 +25,7 @@ struct vm_area_struct;
 #define ___GFP_FS		0x80u
 #define ___GFP_COLD		0x100u
 #define ___GFP_NOWARN		0x200u
-#define ___GFP_RETRY_MAYFAIL		0x400u
+#define ___GFP_RETRY_MAYFAIL	0x400u
 #define ___GFP_NOFAIL		0x800u
 #define ___GFP_NORETRY		0x1000u
 #define ___GFP_MEMALLOC		0x2000u
@@ -139,10 +139,11 @@ struct vm_area_struct;
  * The default allocator behavior depends on the request size. We have a concept
  * of so called costly allocations (with order > PAGE_ALLOC_COSTLY_ORDER).
  * !costly allocations are too essential to fail so they are implicitly
- * non-failing (with some exceptions like OOM victims might fail) by default while
- * costly requests try to be not disruptive and back off even without invoking
- * the OOM killer. The following three modifiers might be used to override some of
- * these implicit rules
+ * non-failing by default (with some exceptions like OOM victims might fail so
+ * the caller still has to check for failures) while costly requests try to be
+ * not disruptive and back off even without invoking the OOM killer.
+ * The following three modifiers might be used to override some of these
+ * implicit rules
  *
  * __GFP_NORETRY: The VM implementation will try only very lightweight
  *   memory direct reclaim to get some memory under memory pressure (thus
@@ -157,7 +158,7 @@ struct vm_area_struct;
  *   tasks to attempt high level approaches to freeing memory such as
  *   compaction (which removes fragmentation) and page-out.
  *   There is still a definite limit to the number of retries, but it is
- *   a larger limit than with __GFP_NORERY.
+ *   a larger limit than with __GFP_NORETRY.
  *   Allocations with this flag may fail, but only when there is
  *   genuinely little unused memory. While these allocations do not
  *   directly trigger the OOM killer, their failure indicates that
-- 
2.11.0

-- 
Michal Hocko
SUSE Labs

  reply index

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-23  8:53 [PATCH 0/6] mm: give __GFP_REPEAT a better semantic Michal Hocko
2017-06-23  8:53 ` [PATCH 1/6] MIPS: do not use __GFP_REPEAT for order-0 request Michal Hocko
2017-06-23 10:27   ` Ralf Baechle
2017-06-26  9:36   ` Vlastimil Babka
2017-06-23  8:53 ` [PATCH 2/6] mm, tree wide: replace __GFP_REPEAT by __GFP_RETRY_MAYFAIL with more useful semantic Michal Hocko
2017-06-26 11:45   ` Vlastimil Babka
2017-06-26 12:14     ` Michal Hocko
2017-06-26 12:17       ` Vlastimil Babka
2017-06-26 12:38         ` Michal Hocko
2017-06-26 12:42           ` Michal Hocko [this message]
2017-06-26 11:53   ` Vlastimil Babka
2017-06-23  8:53 ` [PATCH 3/6] xfs: map KM_MAYFAIL to __GFP_RETRY_MAYFAIL Michal Hocko
2017-06-27  8:49   ` Michal Hocko
2017-06-27 13:47     ` Christoph Hellwig
2017-06-27 14:06       ` Michal Hocko
2017-06-28  4:12         ` Darrick J. Wong
2017-06-23  8:53 ` [PATCH 4/6] mm: kvmalloc support __GFP_RETRY_MAYFAIL for all sizes Michal Hocko
2017-06-26 12:00   ` Vlastimil Babka
2017-06-26 12:18     ` Michal Hocko
2017-06-23  8:53 ` [PATCH 5/6] drm/i915: use __GFP_RETRY_MAYFAIL Michal Hocko
2017-06-23  8:53 ` [PATCH 6/6] mm, migration: do not trigger OOM killer when migrating memory Michal Hocko
2017-06-23 20:43   ` Andrew Morton
2017-06-26  5:28     ` Michal Hocko
2017-06-26 12:13   ` Vlastimil Babka

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=20170626124233.GN11534@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=neilb@suse.com \
    --cc=vbabka@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

LKML Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git
	git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git
	git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git
	git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git
	git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git
	git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git
	git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git
	git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git
	git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git
	git clone --mirror https://lore.kernel.org/lkml/9 lkml/git/9.git
	git clone --mirror https://lore.kernel.org/lkml/10 lkml/git/10.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \
		linux-kernel@vger.kernel.org
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git