Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754718AbcK2Rsp (ORCPT ); Tue, 29 Nov 2016 12:48:45 -0500 Received: from mail-io0-f193.google.com ([209.85.223.193]:35743 "EHLO mail-io0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751494AbcK2Rsg (ORCPT ); Tue, 29 Nov 2016 12:48:36 -0500 MIME-Version: 1.0 In-Reply-To: <20161129172854.GF9796@dhcp22.suse.cz> References: <7189b1f6-98c3-9a36-83c1-79f2ff4099af@suse.cz> <20161122164822.GA5459@htj.duckdns.org> <3e8eeadb-8dde-2313-f6e3-ef7763832104@suse.cz> <20161128171907.GA14754@htj.duckdns.org> <20161129072507.GA31671@dhcp22.suse.cz> <20161129163807.GB19454@htj.duckdns.org> <20161129171333.GE9796@dhcp22.suse.cz> <20161129172854.GF9796@dhcp22.suse.cz> From: Linus Torvalds Date: Tue, 29 Nov 2016 09:48:34 -0800 X-Google-Sender-Auth: bucYhWH0PYQS8tZfxd8YjDalX4U Message-ID: Subject: Re: [PATCH] block,blkcg: use __GFP_NOWARN for best-effort allocations in blkcg To: Michal Hocko Cc: Vlastimil Babka , Tejun Heo , Jens Axboe , linux-mm , LKML , Joonsoo Kim , Marc MERLIN Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1696 Lines: 47 On Tue, Nov 29, 2016 at 9:28 AM, Michal Hocko 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