Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753970AbdIFP7M (ORCPT ); Wed, 6 Sep 2017 11:59:12 -0400 Received: from resqmta-ch2-08v.sys.comcast.net ([69.252.207.40]:42130 "EHLO resqmta-ch2-08v.sys.comcast.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752639AbdIFP7L (ORCPT ); Wed, 6 Sep 2017 11:59:11 -0400 Date: Wed, 6 Sep 2017 10:59:09 -0500 (CDT) From: Christopher Lameter X-X-Sender: cl@nuc-kabylake To: js1304@gmail.com cc: Andrew Morton , Pekka Enberg , David Rientjes , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Mel Gorman , Vlastimil Babka , Michal Hocko , Joonsoo Kim Subject: Re: [PATCH 1/2] mm/slub: wake up kswapd for initial high order allocation In-Reply-To: <1504672666-19682-1-git-send-email-iamjoonsoo.kim@lge.com> Message-ID: References: <1504672666-19682-1-git-send-email-iamjoonsoo.kim@lge.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-CMAE-Envelope: MS4wfJ4EMOAJ4/eDnSYiEZzXEcyEoOR+0CI9gCou4RwqSnnh4Iz5cGZfau98PPRZyQlNpbQhYupaGmz3kclBBEQFCTSjhgr92FOJTYBgW3JGuePZH+1LmIlH 2wzaZ57yvEj17f0yQ/LlZx286qd08qoSxN5pnSmFNuz3lVLS5tW60peZL4V2IJ/ohu6y9i0fBGJIOQbxf0xZddkorIV9aupitiFF3keQgl9+67q+TUN9Dj1k TcmFUFKWEvRC/iI9ymMSmRpQAx59bfDUWtEcX426eXvbXTXy4FLF7MGJguX1BXqxrj9uS5TOKP7Qafft1i2nW68YsJZD+SORSqW3YSwutxfIMvhPZHg4uE4u /UWZsHGIgKoLdqj3bNYUzKRmq0T2C+6HHpzA7CRRzKaVgYz0YwvN5YbRf8ZoF3openGrCKHio/F9kuVo33wHky12lojIWWXM4KZYnhVtOR+AH1q+mDA= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 942 Lines: 24 On Wed, 6 Sep 2017, js1304@gmail.com wrote: > --- a/mm/slub.c > +++ b/mm/slub.c > @@ -1578,8 +1578,12 @@ static struct page *allocate_slab(struct kmem_cache *s, gfp_t flags, int node) > * so we fall-back to the minimum order allocation. > */ > alloc_gfp = (flags | __GFP_NOWARN | __GFP_NORETRY) & ~__GFP_NOFAIL; > - if ((alloc_gfp & __GFP_DIRECT_RECLAIM) && oo_order(oo) > oo_order(s->min)) > - alloc_gfp = (alloc_gfp | __GFP_NOMEMALLOC) & ~(__GFP_RECLAIM|__GFP_NOFAIL); > + if (oo_order(oo) > oo_order(s->min)) { > + if (alloc_gfp & __GFP_DIRECT_RECLAIM) { > + alloc_gfp |= __GFP_NOMEMALLOC; > + alloc_gfp &= ~__GFP_DIRECT_RECLAIM; > + } > + } > Can we come up with another inline function in gfp.h for this as well? Well and needing these functions to manipulate flags actually indicates that we may need a cleanup of the GFP flags at some point. There is a buch of flags that disable things and some that enable things.