All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka@suse.cz>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	Tejun Heo <tj@kernel.org>
Cc: Jens Axboe <axboe@kernel.dk>, linux-mm <linux-mm@kvack.org>,
	Michal Hocko <mhocko@kernel.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: Wed, 23 Nov 2016 09:50:12 +0100	[thread overview]
Message-ID: <3e8eeadb-8dde-2313-f6e3-ef7763832104@suse.cz> (raw)
In-Reply-To: <CA+55aFwEik1Q-D0d4pRTNq672RS2eHpT2ULzGfttaSWW69Tajw@mail.gmail.com>

On 11/22/2016 11:13 PM, Linus Torvalds wrote:
> On Tue, Nov 22, 2016 at 8:48 AM, Tejun Heo <tj@kernel.org> wrote:
>>
>> Hello,
>>
>> On Tue, Nov 22, 2016 at 04:47:49PM +0100, Vlastimil Babka wrote:
>>> Thanks. Makes me wonder whether we should e.g. add __GFP_NOWARN to
>>> GFP_NOWAIT globally at some point.
>>
>> Yeah, that makes sense.  The caller is explicitly saying that it's
>> okay to fail the allocation.
>
> I'm not so convinced about the "atomic automatically means you shouldn't warn".

Right, but atomic allocations should be using GFP_ATOMIC, which allows 
to use the atomic reserves. I meant here just GFP_NOWAIT which does not 
allow reserves, for allocations that are not in atomic context, but 
still don't want to reclaim for performance or whatever reasons, and 
have a suitable fallback. It's their choice to not spend any effort on 
the allocation and thus they shouldn't spew warnings IMHO.

> 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.

Vlastimil

> Because as it is, atomic allocations certainly get to dig deeper into
> our memory reserves, but they most definitely can fail, and I
> definitely see how some code has no fallback because it thinks that
> the deeper reserves mean that it will succeed.
>
>              Linus
>

WARNING: multiple messages have this Message-ID (diff)
From: Vlastimil Babka <vbabka@suse.cz>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	Tejun Heo <tj@kernel.org>
Cc: Jens Axboe <axboe@kernel.dk>, linux-mm <linux-mm@kvack.org>,
	Michal Hocko <mhocko@kernel.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: Wed, 23 Nov 2016 09:50:12 +0100	[thread overview]
Message-ID: <3e8eeadb-8dde-2313-f6e3-ef7763832104@suse.cz> (raw)
In-Reply-To: <CA+55aFwEik1Q-D0d4pRTNq672RS2eHpT2ULzGfttaSWW69Tajw@mail.gmail.com>

On 11/22/2016 11:13 PM, Linus Torvalds wrote:
> On Tue, Nov 22, 2016 at 8:48 AM, Tejun Heo <tj@kernel.org> wrote:
>>
>> Hello,
>>
>> On Tue, Nov 22, 2016 at 04:47:49PM +0100, Vlastimil Babka wrote:
>>> Thanks. Makes me wonder whether we should e.g. add __GFP_NOWARN to
>>> GFP_NOWAIT globally at some point.
>>
>> Yeah, that makes sense.  The caller is explicitly saying that it's
>> okay to fail the allocation.
>
> I'm not so convinced about the "atomic automatically means you shouldn't warn".

Right, but atomic allocations should be using GFP_ATOMIC, which allows 
to use the atomic reserves. I meant here just GFP_NOWAIT which does not 
allow reserves, for allocations that are not in atomic context, but 
still don't want to reclaim for performance or whatever reasons, and 
have a suitable fallback. It's their choice to not spend any effort on 
the allocation and thus they shouldn't spew warnings IMHO.

> 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.

Vlastimil

> Because as it is, atomic allocations certainly get to dig deeper into
> our memory reserves, but they most definitely can fail, and I
> definitely see how some code has no fallback because it thinks that
> the deeper reserves mean that it will succeed.
>
>              Linus
>

--
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-23  8:50 UTC|newest]

Thread overview: 113+ 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:50   ` Vlastimil Babka
2016-11-21 21:56   ` Marc MERLIN
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-21 23:03       ` Tejun Heo
2016-11-22 15:47       ` Vlastimil Babka
2016-11-22 15:47         ` Vlastimil Babka
2016-11-22 16:48         ` Tejun Heo
2016-11-22 16:48           ` Tejun Heo
2016-11-22 22:13           ` Linus Torvalds
2016-11-22 22:13             ` Linus Torvalds
2016-11-23  8:50             ` Vlastimil Babka [this message]
2016-11-23  8:50               ` Vlastimil Babka
2016-11-28 17:19               ` Tejun Heo
2016-11-28 17:19                 ` Tejun Heo
2016-11-29  7:25                 ` Michal Hocko
2016-11-29  7:25                   ` Michal Hocko
2016-11-29 16:38                   ` Tejun Heo
2016-11-29 16:38                     ` Tejun Heo
2016-11-29 16:57                     ` Vlastimil Babka
2016-11-29 16:57                       ` Vlastimil Babka
2016-11-29 17:13                       ` Michal Hocko
2016-11-29 17:13                         ` Michal Hocko
2016-11-29 17:17                         ` Linus Torvalds
2016-11-29 17:17                           ` Linus Torvalds
2016-11-29 17:28                           ` Michal Hocko
2016-11-29 17:28                             ` Michal Hocko
2016-11-29 17:48                             ` Linus Torvalds
2016-11-29 17:48                               ` Linus Torvalds
2016-11-22 16:00       ` Jens Axboe
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:06       ` Marc MERLIN
2016-11-22 16:14       ` Vlastimil Babka
2016-11-22 16:14         ` Vlastimil Babka
2016-11-22 16:25         ` Michal Hocko
2016-11-22 16:25           ` Michal Hocko
2016-11-22 16:47           ` Marc MERLIN
2016-11-22 16:47             ` Marc MERLIN
2016-11-22 16:38         ` Greg Kroah-Hartman
2016-11-22 16:38           ` Greg Kroah-Hartman
2016-11-29 16:25           ` Michal Hocko
2016-11-29 16:25             ` Michal Hocko
2016-11-29 16:25             ` Michal Hocko
2016-11-29 16:43             ` Patch "mm, oom: stop pre-mature high-order OOM killer invocations" has been added to the 4.8-stable tree gregkh
2016-11-29 16:43             ` 4.8.8 kernel trigger OOM killer repeatedly when I have lots of RAM that should be free Greg Kroah-Hartman
2016-11-29 16:43               ` Greg Kroah-Hartman
2016-11-22 19:38         ` Linus Torvalds
2016-11-22 19:38           ` Linus Torvalds
2016-11-23  6:34           ` Michal Hocko
2016-11-23  6:34             ` Michal Hocko
2016-11-23  6:53             ` Hillf Danton
2016-11-23  6:53               ` Hillf Danton
2016-11-23  7:00               ` Michal Hocko
2016-11-23  7:00                 ` Michal Hocko
2016-11-23  9:18             ` Vlastimil Babka
2016-11-23  9:18               ` Vlastimil Babka
2016-11-28  7:23             ` Michal Hocko
2016-11-28  7:23               ` Michal Hocko
2016-11-28 20:55               ` Marc MERLIN
2016-11-29 15:55               ` Marc MERLIN
2016-11-29 15:55                 ` Marc MERLIN
2016-11-29 16:07                 ` Michal Hocko
2016-11-29 16:07                   ` Michal Hocko
2016-11-29 16:34                   ` Marc MERLIN
2016-11-29 16:34                     ` Marc MERLIN
2016-11-29 17:07                     ` Linus Torvalds
2016-11-29 17:07                       ` Linus Torvalds
2016-11-29 17:40                       ` Marc MERLIN
2016-11-29 17:40                         ` Marc MERLIN
2016-11-29 18:01                         ` Linus Torvalds
2016-11-29 18:01                           ` Linus Torvalds
2016-11-30 17:47                           ` Marc MERLIN
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:21                                 ` Marc MERLIN
2016-11-30 18:27                               ` Jens Axboe
2016-11-30 18:27                                 ` Jens Axboe
2016-11-30 20:30                               ` Tejun Heo
2016-11-30 20:30                                 ` Tejun Heo
2016-12-01 13:50                                 ` Kent Overstreet
2016-12-01 13:50                                   ` Kent Overstreet
2016-12-01 18:16                                   ` Linus Torvalds
2016-12-01 18:16                                     ` Linus Torvalds
2016-12-01 18:30                                     ` Jens Axboe
2016-12-01 18:30                                       ` Jens Axboe
2016-12-01 18:37                                       ` Linus Torvalds
2016-12-01 18:37                                         ` Linus Torvalds
2016-12-01 18:46                                         ` Jens Axboe
2016-12-01 18:46                                           ` Jens Axboe
2016-11-29 20:11                         ` Holger Hoffstätte
2016-11-29 23:01                         ` Marc MERLIN
2016-11-29 23:01                           ` Marc MERLIN
2016-11-30 13:58                           ` Tetsuo Handa
2016-11-30 13:58                             ` Tetsuo Handa
2017-05-02  4:12                           ` Marc MERLIN
2017-05-02  4:12                             ` Marc MERLIN
2017-05-02  7:44                             ` Michal Hocko
2017-05-02  7:44                               ` Michal Hocko
2017-05-02 14:15                               ` Marc MERLIN
2017-05-02 14:15                                 ` Marc MERLIN
2017-05-02 10:44                             ` Tetsuo Handa
2017-05-02 10:44                               ` Tetsuo Handa
2016-11-29 16:15               ` Marc MERLIN
2016-11-29 16:15                 ` Marc MERLIN
2016-11-22 21:46         ` Simon Kirby
2016-11-22 21:46           ` Simon Kirby
2016-11-28  8:06           ` Vlastimil Babka
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=3e8eeadb-8dde-2313-f6e3-ef7763832104@suse.cz \
    --to=vbabka@suse.cz \
    --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=mhocko@kernel.org \
    --cc=tj@kernel.org \
    --cc=torvalds@linux-foundation.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.