From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S932358AbdIFRVR (ORCPT <rfc822;w@1wt.eu>);
        Wed, 6 Sep 2017 13:21:17 -0400
Received: from mx2.suse.de ([195.135.220.15]:53696 "EHLO mx1.suse.de"
        rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP
        id S932167AbdIFRVO (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 6 Sep 2017 13:21:14 -0400
Date: Wed, 6 Sep 2017 19:21:10 +0200
From: Michal Hocko <mhocko@kernel.org>
To: Christopher Lameter <cl@linux.com>
Cc: js1304@gmail.com, Andrew Morton <akpm@linux-foundation.org>,
        Pekka Enberg <penberg@kernel.org>,
        David Rientjes <rientjes@google.com>, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org, Mel Gorman <mgorman@techsingularity.net>,
        Vlastimil Babka <vbabka@suse.cz>, Joonsoo Kim <iamjoonsoo.kim@lge.com>
Subject: Re: [PATCH 1/2] mm/slub: wake up kswapd for initial high order
 allocation
Message-ID: <20170906172110.m7ag4ox34fcscg4x@dhcp22.suse.cz>
References: <1504672666-19682-1-git-send-email-iamjoonsoo.kim@lge.com>
 <alpine.DEB.2.20.1709061056270.13344@nuc-kabylake>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.20.1709061056270.13344@nuc-kabylake>
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed 06-09-17 10:59:09, Cristopher Lameter wrote:
> 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?

What do you mean? The oo_order thing?

> 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.

Good luck with that
-- 
Michal Hocko
SUSE Labs