Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755376AbcK2QiS (ORCPT ); Tue, 29 Nov 2016 11:38:18 -0500 Received: from mail-yw0-f196.google.com ([209.85.161.196]:33434 "EHLO mail-yw0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751774AbcK2QiJ (ORCPT ); Tue, 29 Nov 2016 11:38:09 -0500 Date: Tue, 29 Nov 2016 11:38:07 -0500 From: Tejun Heo To: Michal Hocko Cc: Vlastimil Babka , Linus Torvalds , 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: <20161129163807.GB19454@htj.duckdns.org> 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> <3e8eeadb-8dde-2313-f6e3-ef7763832104@suse.cz> <20161128171907.GA14754@htj.duckdns.org> <20161129072507.GA31671@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161129072507.GA31671@dhcp22.suse.cz> User-Agent: Mutt/1.7.1 (2016-10-04) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 794 Lines: 20 On Tue, Nov 29, 2016 at 08:25:07AM +0100, Michal Hocko wrote: > --- a/include/linux/gfp.h > +++ b/include/linux/gfp.h > @@ -246,7 +246,7 @@ struct vm_area_struct; > #define GFP_ATOMIC (__GFP_HIGH|__GFP_ATOMIC|__GFP_KSWAPD_RECLAIM) > #define GFP_KERNEL (__GFP_RECLAIM | __GFP_IO | __GFP_FS) > #define GFP_KERNEL_ACCOUNT (GFP_KERNEL | __GFP_ACCOUNT) > -#define GFP_NOWAIT (__GFP_KSWAPD_RECLAIM) > +#define GFP_NOWAIT (__GFP_KSWAPD_RECLAIM|__GFP_NOWARN) > #define GFP_NOIO (__GFP_RECLAIM) > #define GFP_NOFS (__GFP_RECLAIM | __GFP_IO) > #define GFP_TEMPORARY (__GFP_RECLAIM | __GFP_IO | __GFP_FS | \ > > this will not catch users who are doing gfp & ~__GFP_DIRECT_RECLAIM but > I would rather not make warn_alloc() even more cluttered with checks. Yeah, FWIW, looks good to me. -- tejun