Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933842AbcKWIuq (ORCPT ); Wed, 23 Nov 2016 03:50:46 -0500 Received: from mx2.suse.de ([195.135.220.15]:53075 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933274AbcKWIuS (ORCPT ); Wed, 23 Nov 2016 03:50:18 -0500 Subject: Re: [PATCH] block,blkcg: use __GFP_NOWARN for best-effort allocations in blkcg To: Linus Torvalds , Tejun Heo References: <20161121154336.GD19750@merlins.org> <0d4939f3-869d-6fb8-0914-5f74172f8519@suse.cz> <20161121215639.GF13371@merlins.org> <20161121230332.GA3767@htj.duckdns.org> <7189b1f6-98c3-9a36-83c1-79f2ff4099af@suse.cz> <20161122164822.GA5459@htj.duckdns.org> Cc: Jens Axboe , linux-mm , Michal Hocko , LKML , Joonsoo Kim , Marc MERLIN From: Vlastimil Babka Message-ID: <3e8eeadb-8dde-2313-f6e3-ef7763832104@suse.cz> Date: Wed, 23 Nov 2016 09:50:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1589 Lines: 38 On 11/22/2016 11:13 PM, Linus Torvalds wrote: > On Tue, Nov 22, 2016 at 8:48 AM, Tejun Heo 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 >