Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp4610677ybf; Wed, 4 Mar 2020 07:17:03 -0800 (PST) X-Google-Smtp-Source: ADFU+vvWg1mvvoHyoTddXHnesEMjFNQsEDFU6lpcAAVvbo3297MspGwa5dpj4Lt3t0y8G0HW17lT X-Received: by 2002:aca:c256:: with SMTP id s83mr2127131oif.57.1583335023037; Wed, 04 Mar 2020 07:17:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583335023; cv=none; d=google.com; s=arc-20160816; b=I4Bv/AphNu5DWAtZndt8lgSQNiMy4VmNaPSwnTMv0GwY08rsXgu7nQHa6l2SUin/f0 hSuW0BsOte0/o9zznU+4EbqsM9aQyYVNI7qGK2QuPSedjE11vFWMF6al4kVXhXP/CpHj qtAIYvT2Oc0VCxmt6ICK8s0SPazBOC1fOTBeSqSsuYmtBw03+WQ11uk0aezsSCNzd3eF mu4h+ITfBH07MkD6OLZBpBlBs5RBcL2QXA0W0sJIW1gpZNg3MLiz3pJ2Cuif4kkR9Toi 8r846fw3F87RCckYeHkDX9Cw9iItCJkAbTar5A5FLl6QZ6FsAKOZAn1vJoruxhND3hB6 efLQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=qjEqLKUngMaZ/BJwjX3u+N0onB1DJnKVHWAXk5/GE3A=; b=U10YKZX+rI+FdudUT7By7j24dZ2994YCyPSyk0SzgvlTOdJNYnpsDfu5fPIjYukzLp KVaQoEo/TWQzyRuDMNGP2WOVQpXuDux1FUoHbmHXyCQCinJf79PEPSVCG2vQ1kd+fwWc h6F+ukDcMv6D8wDk5byBhmPXOI1Gu354KbUda92OSJ6QDYql3AFp/F6cbjpDKcZ6HSQh 0tkNl2Zwx8eLeezrwnyGnbQZpgF4zllhG/uRt1ZcSDN6gCrBfOCBBB33KMy1eutcYuqk GdRuSj0YQb3SEP56cf+0p3KRB/aYQtpF/UoNWH6NwoLqv4Dbp7agzKLeP4A5uSa/GQYK ROkg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i66si1397012oib.237.2020.03.04.07.16.49; Wed, 04 Mar 2020 07:17:03 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729523AbgCDPPS (ORCPT + 99 others); Wed, 4 Mar 2020 10:15:18 -0500 Received: from outbound-smtp31.blacknight.com ([81.17.249.62]:48434 "EHLO outbound-smtp31.blacknight.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726740AbgCDPPS (ORCPT ); Wed, 4 Mar 2020 10:15:18 -0500 Received: from mail.blacknight.com (pemlinmail04.blacknight.ie [81.17.254.17]) by outbound-smtp31.blacknight.com (Postfix) with ESMTPS id EC871C0B3B for ; Wed, 4 Mar 2020 15:15:15 +0000 (GMT) Received: (qmail 18781 invoked from network); 4 Mar 2020 15:15:15 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.18.57]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 4 Mar 2020 15:15:15 -0000 Date: Wed, 4 Mar 2020 15:15:13 +0000 From: Mel Gorman To: mateusznosek0@gmail.com Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org Subject: Re: [RFC PATCH] mm: Micro-optimisation: Save two branches on hot - page allocation path Message-ID: <20200304151513.GO3818@techsingularity.net> References: <20200304142230.8753-1-mateusznosek0@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20200304142230.8753-1-mateusznosek0@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 04, 2020 at 03:22:30PM +0100, mateusznosek0@gmail.com wrote: > From: Mateusz Nosek > > This patch makes ALLOC_KSWAPD > equal to __GFP_KSWAPD_RACLAIM (cast to 'int'). > s/RACLAIM/RECLAIM/ Very strange word wrapping > Thanks to that code like: > ```if (gfp_mask & __GFP_KSWAPD_RECLAIM) > alloc_flags |= ALLOC_KSWAPD;``` > can be changed to: > ```alloc_flags |= (__force int) (gfp_mask &__GFP_KSWAPD_RECLAIM);``` Not sure what the multiple ``` are about. It does not appear to be an encoding error but I think you can drop them. Maybe some mail readers render this differently but it looks weird in plain text. > Thanks to this one branch less is generated in the assembly. > > In case of ALLOC_KSWAPD flag two branches are saved, > first one in code that always executes in the beggining of page allocation s/beggining/beginning/ > and the second one in loop in page allocator slowpath. Also strange word wrapping. > > Signed-off-by: Mateusz Nosek > --- > mm/internal.h | 2 +- > mm/page_alloc.c | 23 +++++++++++++++-------- > 2 files changed, 16 insertions(+), 9 deletions(-) > > diff --git a/mm/internal.h b/mm/internal.h > index 86372d164476..7fb724977743 100644 > --- a/mm/internal.h > +++ b/mm/internal.h > @@ -535,7 +535,7 @@ unsigned long reclaim_clean_pages_from_list(struct zone *zone, > #else > #define ALLOC_NOFRAGMENT 0x0 > #endif > -#define ALLOC_KSWAPD 0x200 /* allow waking of kswapd */ > +#define ALLOC_KSWAPD 0x800 /* allow waking of kswapd */ > > enum ttu_flags; > struct tlbflush_unmap_batch; > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 79e950d76ffc..73afd883eab5 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -3609,10 +3609,14 @@ static bool zone_allows_reclaim(struct zone *local_zone, struct zone *zone) > static inline unsigned int > alloc_flags_nofragment(struct zone *zone, gfp_t gfp_mask) > { > - unsigned int alloc_flags = 0; > + unsigned int alloc_flags; > > - if (gfp_mask & __GFP_KSWAPD_RECLAIM) > - alloc_flags |= ALLOC_KSWAPD; > + /* > + * __GFP_KSWAPD_RECLAIM is assumed to be the same as ALLOC_KSWAPD > + * to save a branch. > + */ > + BUILD_BUG_ON(__GFP_KSWAPD_RECLAIM != (__force gfp_t) ALLOC_KSWAPD); > + alloc_flags = (__force int) (gfp_mask & __GFP_KSWAPD_RECLAIM); > > #ifdef CONFIG_ZONE_DMA32 > if (!zone) Ok, that looks reasonable. > @@ -4248,8 +4252,13 @@ gfp_to_alloc_flags(gfp_t gfp_mask) > { > unsigned int alloc_flags = ALLOC_WMARK_MIN | ALLOC_CPUSET; > > - /* __GFP_HIGH is assumed to be the same as ALLOC_HIGH to save a branch. */ > + /* > + * __GFP_HIGH is assumed to be the same as ALLOC_HIGH > + * and __GFP_KSWAPD_RECLAIM is assumed to be the same as ALLOC_KSWAPD > + * to save two branches. > + */ > BUILD_BUG_ON(__GFP_HIGH != (__force gfp_t) ALLOC_HIGH); > + BUILD_BUG_ON(__GFP_KSWAPD_RECLAIM != (__force gfp_t) ALLOC_KSWAPD); > > /* > * The caller may dip into page reserves a bit more if the caller As Vlastimil pointed out, you do not need to make two compiler-based checks. This seems like a reasonable location given that gfp_to_alloc_flags is the most obvious place to document tricks with the flags. > @@ -4257,7 +4266,8 @@ gfp_to_alloc_flags(gfp_t gfp_mask) > * policy or is asking for __GFP_HIGH memory. GFP_ATOMIC requests will > * set both ALLOC_HARDER (__GFP_ATOMIC) and ALLOC_HIGH (__GFP_HIGH). > */ > - alloc_flags |= (__force int) (gfp_mask & __GFP_HIGH); > + alloc_flags |= (__force int) > + (gfp_mask & (__GFP_HIGH | __GFP_KSWAPD_RECLAIM)); > > if (gfp_mask & __GFP_ATOMIC) { > /* Slightly harder to read but it does potentially generate better code. If you correct the typos in the changelog, the slightly strange formatting of the changelog and drop one of the build checks then you can add Acked-by: Mel Gorman -- Mel Gorman SUSE Labs