Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756684AbcK2R3E (ORCPT ); Tue, 29 Nov 2016 12:29:04 -0500 Received: from mail-wj0-f193.google.com ([209.85.210.193]:34413 "EHLO mail-wj0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756020AbcK2R24 (ORCPT ); Tue, 29 Nov 2016 12:28:56 -0500 Date: Tue, 29 Nov 2016 18:28:54 +0100 From: Michal Hocko To: Linus Torvalds Cc: Vlastimil Babka , Tejun Heo , Jens Axboe , linux-mm , LKML , Joonsoo Kim , Marc MERLIN Subject: Re: [PATCH] block,blkcg: use __GFP_NOWARN for best-effort allocations in blkcg Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1043 Lines: 30 On Tue 29-11-16 09:17:37, Linus Torvalds wrote: > On Tue, Nov 29, 2016 at 9:13 AM, Michal Hocko wrote: > > How does this look like? > > No. > > I *really* want people to write out that "I am ok with the allocation failing". > > It's not an "inconvenience". It's a sign that you are competent and > that you know it will fail, and that you can handle it. > > If you don't show that you know that, we warn about it. 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. >From my experience people tend to report those and worry about them (quite often confusing them with the real OOM) and we usually only can explain that this is nothing to worry about... And so then we sprinkle GFP_NOWARN all over the place as we hit those. Is this really what we want? > And no, "GFP_NOWAIT" does *not* mean "I have a good fallback". I am confused, how can anybody _rely_ on GFP_NOWAIT to succeed? -- Michal Hocko SUSE Labs