linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Tejun Heo <tj@kernel.org>
Cc: Vlastimil Babka <vbabka@suse.cz>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Jens Axboe <axboe@kernel.dk>, linux-mm <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Marc MERLIN <marc@merlins.org>
Subject: Re: [PATCH] block,blkcg: use __GFP_NOWARN for best-effort allocations in blkcg
Date: Tue, 29 Nov 2016 08:25:07 +0100	[thread overview]
Message-ID: <20161129072507.GA31671@dhcp22.suse.cz> (raw)
In-Reply-To: <20161128171907.GA14754@htj.duckdns.org>

On Mon 28-11-16 12:19:07, Tejun Heo wrote:
> Hello,
> 
> On Wed, Nov 23, 2016 at 09:50:12AM +0100, Vlastimil Babka wrote:
> > > You'd certainly _hope_ that atomic allocations either have fallbacks
> > > or are harmless if they fail, but I'd still rather see that
> > > __GFP_NOWARN just to make that very much explicit.
> > 
> > A global change to GFP_NOWAIT would of course mean that we should audit its
> > users (there don't seem to be many), whether they are using it consciously
> > and should not rather be using GFP_ATOMIC.
> 
> A while ago, I thought about something like, say, GFP_MAYBE which is
> combination of NOWAIT and NOWARN but couldn't really come up with
> scenarios where one would want to use NOWAIT w/o NOWARN.  If an
> allocation is important enough to warn the user of its failure, it
> better be dipping into the atomic reserve pool; otherwise, it doesn't
> make sense to make noise.

I do not think we really need a new flag for that and fully agree that
GFP_NOWAIT warning about failure is rarely, if ever, useful.
Historically we didn't use to distinguish atomic (with access to
reserves) allocations from those which just do not want to trigger the
reclaim resp. to sleep (aka optimistic allocation requests). But this
has changed so I guess we can really do the following 
diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index f8041f9de31e..a53b5187b4da 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -246,7 +246,7 @@ struct vm_area_struct;
 #define GFP_ATOMIC	(__GFP_HIGH|__GFP_ATOMIC|__GFP_KSWAPD_RECLAIM)
 #define GFP_KERNEL	(__GFP_RECLAIM | __GFP_IO | __GFP_FS)
 #define GFP_KERNEL_ACCOUNT (GFP_KERNEL | __GFP_ACCOUNT)
-#define GFP_NOWAIT	(__GFP_KSWAPD_RECLAIM)
+#define GFP_NOWAIT	(__GFP_KSWAPD_RECLAIM|__GFP_NOWARN)
 #define GFP_NOIO	(__GFP_RECLAIM)
 #define GFP_NOFS	(__GFP_RECLAIM | __GFP_IO)
 #define GFP_TEMPORARY	(__GFP_RECLAIM | __GFP_IO | __GFP_FS | \

this will not catch users who are doing gfp & ~__GFP_DIRECT_RECLAIM but
I would rather not make warn_alloc() even more cluttered with checks.
-- 
Michal Hocko
SUSE Labs

--
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:[~2016-11-29  7:25 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-21 15:43 4.8.8 kernel trigger OOM killer repeatedly when I have lots of RAM that should be free Marc MERLIN
2016-11-21 16:30 ` Marc MERLIN
2016-11-21 21:50 ` Vlastimil Babka
2016-11-21 21:56   ` Marc MERLIN
2016-11-21 23:03     ` [PATCH] block,blkcg: use __GFP_NOWARN for best-effort allocations in blkcg Tejun Heo
2016-11-22 15:47       ` Vlastimil Babka
2016-11-22 16:48         ` Tejun Heo
2016-11-22 22:13           ` Linus Torvalds
2016-11-23  8:50             ` Vlastimil Babka
2016-11-28 17:19               ` Tejun Heo
2016-11-29  7:25                 ` Michal Hocko [this message]
2016-11-29 16:38                   ` Tejun Heo
2016-11-29 16:57                     ` Vlastimil Babka
2016-11-29 17:13                       ` Michal Hocko
2016-11-29 17:17                         ` Linus Torvalds
2016-11-29 17:28                           ` Michal Hocko
2016-11-29 17:48                             ` Linus Torvalds
2016-11-22 16:00       ` Jens Axboe
2016-11-22 16:06     ` 4.8.8 kernel trigger OOM killer repeatedly when I have lots of RAM that should be free Marc MERLIN
2016-11-22 16:14       ` Vlastimil Babka
2016-11-22 16:25         ` Michal Hocko
2016-11-22 16:47           ` Marc MERLIN
2016-11-22 16:38         ` Greg Kroah-Hartman
2016-11-29 16:25           ` Michal Hocko
2016-11-29 16:43             ` Greg Kroah-Hartman
2016-11-22 19:38         ` Linus Torvalds
2016-11-23  6:34           ` Michal Hocko
2016-11-23  6:53             ` Hillf Danton
2016-11-23  7:00               ` Michal Hocko
2016-11-23  9:18             ` Vlastimil Babka
2016-11-28  7:23             ` Michal Hocko
2016-11-28 20:55               ` Marc MERLIN
2016-11-29 15:55               ` Marc MERLIN
2016-11-29 16:07                 ` Michal Hocko
2016-11-29 16:34                   ` Marc MERLIN
2016-11-29 17:07                     ` Linus Torvalds
2016-11-29 17:40                       ` Marc MERLIN
2016-11-29 18:01                         ` Linus Torvalds
2016-11-30 17:47                           ` Marc MERLIN
2016-11-30 18:14                             ` Linus Torvalds
2016-11-30 18:21                               ` Marc MERLIN
2016-11-30 18:27                               ` Jens Axboe
2016-11-30 20:30                               ` Tejun Heo
2016-12-01 13:50                                 ` Kent Overstreet
2016-12-01 18:16                                   ` Linus Torvalds
2016-12-01 18:30                                     ` Jens Axboe
2016-12-01 18:37                                       ` Linus Torvalds
2016-12-01 18:46                                         ` Jens Axboe
2016-11-29 20:11                         ` Holger Hoffstätte
2016-11-29 23:01                         ` Marc MERLIN
2016-11-30 13:58                           ` Tetsuo Handa
2017-05-02  4:12                           ` Marc MERLIN
2017-05-02  7:44                             ` Michal Hocko
2017-05-02 14:15                               ` Marc MERLIN
2017-05-02 10:44                             ` Tetsuo Handa
2016-11-29 16:15               ` Marc MERLIN
2016-11-22 21:46         ` Simon Kirby
2016-11-28  8:06           ` 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=20161129072507.GA31671@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=axboe@kernel.dk \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=marc@merlins.org \
    --cc=tj@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --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
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