From: Linus Torvalds <torvalds@linux-foundation.org> To: Michal Hocko <mhocko@kernel.org> Cc: Vlastimil Babka <vbabka@suse.cz>, Tejun Heo <tj@kernel.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 09:48:34 -0800 [thread overview] Message-ID: <CA+55aFxLWUj2uipfg-v+FSoxSH-ZJQrvnZP-Bs_C-Yd-Vqvcqg@mail.gmail.com> (raw) In-Reply-To: <20161129172854.GF9796@dhcp22.suse.cz> On Tue, Nov 29, 2016 at 9:28 AM, Michal Hocko <mhocko@kernel.org> wrote: > How does this warning help those who are watching the logs? What are > they supposed to do about it? Unlike GFP_ATOMIC there is no tuning you > can possibly do. You can report it and it will get fixed. It's not about tuning. It's about people like Tejun who made changes and didn't do them right. In other words, exactly the patch that this whole thread started with. Except that because of the idiotic arguments about the *obvious* patch, the patch gets delayed and not applied. The whole __GFP_NOWARN thing is not some kind of newfangled thing that suddenly became a problem. It's been there for decades. Why are you arguing for stupidly removing it now? > I am confused, how can anybody _rely_ on GFP_NOWAIT to succeed? You can't (except perhaps during bootup). BUT YOU HAVE TO HAVE A FALLBACK, AND SHOW THAT YOU ARE *AWARE* THAT YOU CAN"T RELY ON IT. Christ. What's so hard to understand about this? And no, GFP_NOWAIT is not special. Higher orders have the exact same issue. And they too need that __GFP_NOWARN to show that "yes, I know, and yes, I have a fallback strategy". Because that warning shows real bugs. Seriously. We had fix for this pending for 4.10 already (nfsd just blithely assuming it can do big allocations). So stop the idiotic arguments. The whole point is that lots of people don't think about allocations failing (and NOWAIT and friends do not change that ONE WHIT), and __GFP_NOWARN is there exactly to show that you thought about them. The warning _has_ been useful. We're not hiding it by default, because that makes the whole warning pointless. Really. Linus
WARNING: multiple messages have this Message-ID (diff)
From: Linus Torvalds <torvalds@linux-foundation.org> To: Michal Hocko <mhocko@kernel.org> Cc: Vlastimil Babka <vbabka@suse.cz>, Tejun Heo <tj@kernel.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 09:48:34 -0800 [thread overview] Message-ID: <CA+55aFxLWUj2uipfg-v+FSoxSH-ZJQrvnZP-Bs_C-Yd-Vqvcqg@mail.gmail.com> (raw) In-Reply-To: <20161129172854.GF9796@dhcp22.suse.cz> On Tue, Nov 29, 2016 at 9:28 AM, Michal Hocko <mhocko@kernel.org> wrote: > How does this warning help those who are watching the logs? What are > they supposed to do about it? Unlike GFP_ATOMIC there is no tuning you > can possibly do. You can report it and it will get fixed. It's not about tuning. It's about people like Tejun who made changes and didn't do them right. In other words, exactly the patch that this whole thread started with. Except that because of the idiotic arguments about the *obvious* patch, the patch gets delayed and not applied. The whole __GFP_NOWARN thing is not some kind of newfangled thing that suddenly became a problem. It's been there for decades. Why are you arguing for stupidly removing it now? > I am confused, how can anybody _rely_ on GFP_NOWAIT to succeed? You can't (except perhaps during bootup). BUT YOU HAVE TO HAVE A FALLBACK, AND SHOW THAT YOU ARE *AWARE* THAT YOU CAN"T RELY ON IT. Christ. What's so hard to understand about this? And no, GFP_NOWAIT is not special. Higher orders have the exact same issue. And they too need that __GFP_NOWARN to show that "yes, I know, and yes, I have a fallback strategy". Because that warning shows real bugs. Seriously. We had fix for this pending for 4.10 already (nfsd just blithely assuming it can do big allocations). So stop the idiotic arguments. The whole point is that lots of people don't think about allocations failing (and NOWAIT and friends do not change that ONE WHIT), and __GFP_NOWARN is there exactly to show that you thought about them. The warning _has_ been useful. We're not hiding it by default, because that makes the whole warning pointless. Really. 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>
next prev parent reply other threads:[~2016-11-29 17:48 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 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 [this message] 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=CA+55aFxLWUj2uipfg-v+FSoxSH-ZJQrvnZP-Bs_C-Yd-Vqvcqg@mail.gmail.com \ --to=torvalds@linux-foundation.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=mhocko@kernel.org \ --cc=tj@kernel.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: linkBe 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.