Received: by 10.213.65.68 with SMTP id h4csp232461imn; Wed, 28 Mar 2018 02:31:27 -0700 (PDT) X-Google-Smtp-Source: AIpwx48eyvDAjeXrjnOjsoDpEckFqFEBFiztn28qfRpRTL7Q7QqZRPC05T71V7EuQRRtyEdl9sqx X-Received: by 10.98.58.75 with SMTP id h72mr2328606pfa.209.1522229487385; Wed, 28 Mar 2018 02:31:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522229487; cv=none; d=google.com; s=arc-20160816; b=qq7TYlXhKzk4nV5fTd76542Ax9QVNCIBclYBQN08hBXT3AGC/qRIifcwMUlb4mziKr TVgbeMoa5mqQboRxqiqOzFEhzUQN3NWt4QkFoEXaONWk68bYY9lBpoNs1u1F8rjej6M1 30YbJWbRzqvZTn3UVanFYpgsmGIYk94uoeuBJvIgm15iuCQSCIXzkQsnZonMxIEojbY+ wPkbveoPwlrg/3Z6LfCzWk++NCXItgYAAVQhZyV1UfiEh64ZS4IzdBcwd6qsyjOwtzf3 9xJ2r0EEeD4maD5ovc5wSIMoxguCcFcUVgEYlJc4uX7An9ssVcWjXHiTG4AYSdtZ4Yyc iyww== 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:reply-to:message-id :subject:cc:to:from:date:dkim-signature:arc-authentication-results; bh=iuU9/5odCEJdS8edheEUkQaIQBFOKSlZgXAWalGsq50=; b=rOC0/MdFo9q7Sb+s0nU8odtfZe0JZmhv2SN18FAf9rIzkOf0YWrPyoGv91hEYLTdq+ WMLJ7Cz1S6IfeIQUMSs6fhW3izNPDQBLn6JQ/icH8voh676Lc8+kQWtEWhNWMpYPQYZq g0mEFNzaisNZNNon/+RmU/I9gamD1jYl0Ivxt42SZ+h6QqMPgTAo95hA9akMZsYW50/A 4OEpbQN5kWS4ygm/+2S8qoai9G+LD8z+6vLFJ4mctD0yU3VvDbPHKL5yNZbrpZcAhyxl OO9mPteqIFErtSa/rCyg5V+3+dN2PLF+AC+ZQF58CCuY0X3hq1uC4AFzvINAebvWgjQd FwCQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=iyClOXxl; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k8si2240647pgc.361.2018.03.28.02.31.12; Wed, 28 Mar 2018 02:31:27 -0700 (PDT) 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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=iyClOXxl; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752587AbeC1J0b (ORCPT + 99 others); Wed, 28 Mar 2018 05:26:31 -0400 Received: from mail-pl0-f68.google.com ([209.85.160.68]:42797 "EHLO mail-pl0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752171AbeC1J03 (ORCPT ); Wed, 28 Mar 2018 05:26:29 -0400 Received: by mail-pl0-f68.google.com with SMTP id g20-v6so1216498plo.9 for ; Wed, 28 Mar 2018 02:26:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-disposition:in-reply-to:user-agent; bh=iuU9/5odCEJdS8edheEUkQaIQBFOKSlZgXAWalGsq50=; b=iyClOXxlISEUdYlXKRcwsr0iRq8UVOfTLsdloAzTv+HCBVkB0OHJ6UV0W6MnKn80Uz ixcH5E9D60rTvoYabGLS+ezRpr0NuezcXh2IHEaGU4QpFL/sJAEuSUE0i7Z8JVKezc0F DdB/TlYD3FJzlA0G+LpmKAobYqDhHrLNjLn5jqAg0BBKnmnb4A6AE1ffMdQuXIB0jHzj UyJLwEvrW0W2rofEcEMhnGy1GcNyQhpRi7Cxt/eNq9H8w9pbC9ypRyUXd/6bYXnpqtba VPSjCZiy5MFkJq+wSBArW1pTAJ2/lEyBpNwcPRsQ1fvgWZEgcg4IUKXAz82QdVumczcf ekqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:reply-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=iuU9/5odCEJdS8edheEUkQaIQBFOKSlZgXAWalGsq50=; b=CXrFkOf3GrBhQbLT4nk83NXAlM+LVrxuDjnb8XU/nK5SS+kkAMkoc+U3TDQxkSOT5L Ak035cKZReWPu/3EpkaD6GZXTH85lHde5FSeUxicQtH38uzb4JHEqwjKCSIEMuSkhTHr I3edbhuoK2RwzX3G/912wrso2jcmFpPgPw11UZr4HhylVF36DF5ZYUWH/uf27g0zbqH0 ZkheXDDx6xO8ye2hcpVFV3P6ILM3Kqbu1IjYyHlbgrFa2PPsSbk+hWbuZo3kgCD+NYor 3bNT7G5EqA9hEIopiTD7vCu4YgtTBauICrDeYnlsejgxRJ+MVkSeGOj+2SQLdqUzbOBF F8zA== X-Gm-Message-State: AElRT7Ge0EVNocpcbgQMNa4rkRyXK1Zkd5/iBmaf7xxaM8Jbyr5m0Kwd kV+rjAoh7FPAdMv8aeaXMyA= X-Received: by 2002:a17:902:822:: with SMTP id 31-v6mr3084412plk.200.1522229188659; Wed, 28 Mar 2018 02:26:28 -0700 (PDT) Received: from localhost ([185.92.221.13]) by smtp.gmail.com with ESMTPSA id t28sm7842715pfk.138.2018.03.28.02.26.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Mar 2018 02:26:28 -0700 (PDT) Date: Wed, 28 Mar 2018 17:26:20 +0800 From: Wei Yang To: Jia He Cc: Andrew Morton , Michal Hocko , Catalin Marinas , Mel Gorman , Will Deacon , Mark Rutland , Ard Biesheuvel , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Pavel Tatashin , Daniel Jordan , AKASHI Takahiro , Gioh Kim , Steven Sistare , Daniel Vacek , Eugeniu Rosca , Vlastimil Babka , linux-kernel@vger.kernel.org, linux-mm@kvack.org, James Morse , Steve Capper , x86@kernel.org, Greg Kroah-Hartman , Kate Stewart , Philippe Ombredanne , Johannes Weiner , Kemi Wang , Petr Tesarik , YASUAKI ISHIMATSU , Andrey Ryabinin , Nikolay Borisov , Jia He Subject: Re: [PATCH v3 2/5] mm: page_alloc: reduce unnecessary binary search in memblock_next_valid_pfn() Message-ID: <20180328092620.GA98648@WeideMacBook-Pro.local> Reply-To: Wei Yang References: <1522033340-6575-1-git-send-email-hejianet@gmail.com> <1522033340-6575-3-git-send-email-hejianet@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1522033340-6575-3-git-send-email-hejianet@gmail.com> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Mar 25, 2018 at 08:02:16PM -0700, Jia He wrote: >Commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns >where possible") optimized the loop in memmap_init_zone(). But there is >still some room for improvement. E.g. if pfn and pfn+1 are in the same >memblock region, we can simply pfn++ instead of doing the binary search >in memblock_next_valid_pfn. This patch only works when >CONFIG_HAVE_ARCH_PFN_VALID is enable. > >Signed-off-by: Jia He >--- > include/linux/memblock.h | 2 +- > mm/memblock.c | 73 +++++++++++++++++++++++++++++------------------- > mm/page_alloc.c | 3 +- > 3 files changed, 47 insertions(+), 31 deletions(-) > >diff --git a/include/linux/memblock.h b/include/linux/memblock.h >index efbbe4b..a8fb2ab 100644 >--- a/include/linux/memblock.h >+++ b/include/linux/memblock.h >@@ -204,7 +204,7 @@ void __next_mem_pfn_range(int *idx, int nid, unsigned long *out_start_pfn, > #endif /* CONFIG_HAVE_MEMBLOCK_NODE_MAP */ > > #ifdef CONFIG_HAVE_ARCH_PFN_VALID >-unsigned long memblock_next_valid_pfn(unsigned long pfn); >+unsigned long memblock_next_valid_pfn(unsigned long pfn, int *idx); > #endif > > /** >diff --git a/mm/memblock.c b/mm/memblock.c >index bea5a9c..06c1a08 100644 >--- a/mm/memblock.c >+++ b/mm/memblock.c >@@ -1102,35 +1102,6 @@ void __init_memblock __next_mem_pfn_range(int *idx, int nid, > *out_nid = r->nid; > } > >-#ifdef CONFIG_HAVE_ARCH_PFN_VALID >-unsigned long __init_memblock memblock_next_valid_pfn(unsigned long pfn) >-{ >- struct memblock_type *type = &memblock.memory; >- unsigned int right = type->cnt; >- unsigned int mid, left = 0; >- phys_addr_t addr = PFN_PHYS(++pfn); >- >- do { >- mid = (right + left) / 2; >- >- if (addr < type->regions[mid].base) >- right = mid; >- else if (addr >= (type->regions[mid].base + >- type->regions[mid].size)) >- left = mid + 1; >- else { >- /* addr is within the region, so pfn is valid */ >- return pfn; >- } >- } while (left < right); >- >- if (right == type->cnt) >- return -1UL; >- else >- return PHYS_PFN(type->regions[right].base); >-} >-#endif /*CONFIG_HAVE_ARCH_PFN_VALID*/ >- > /** > * memblock_set_node - set node ID on memblock regions > * @base: base of area to set node ID for >@@ -1162,6 +1133,50 @@ int __init_memblock memblock_set_node(phys_addr_t base, phys_addr_t size, > } > #endif /* CONFIG_HAVE_MEMBLOCK_NODE_MAP */ > >+#ifdef CONFIG_HAVE_ARCH_PFN_VALID >+unsigned long __init_memblock memblock_next_valid_pfn(unsigned long pfn, >+ int *last_idx) >+{ >+ struct memblock_type *type = &memblock.memory; >+ unsigned int right = type->cnt; >+ unsigned int mid, left = 0; >+ unsigned long start_pfn, end_pfn; >+ phys_addr_t addr = PFN_PHYS(++pfn); >+ >+ /* fast path, return pfh+1 if next pfn is in the same region */ ^^^ pfn >+ if (*last_idx != -1) { >+ start_pfn = PFN_DOWN(type->regions[*last_idx].base); To me, it should be PFN_UP(). >+ end_pfn = PFN_DOWN(type->regions[*last_idx].base + >+ type->regions[*last_idx].size); >+ >+ if (pfn < end_pfn && pfn > start_pfn) Could be (pfn < end_pfn && pfn >= start_pfn)? pfn == start_pfn is also a valid address. >+ return pfn; >+ } >+ >+ /* slow path, do the binary searching */ >+ do { >+ mid = (right + left) / 2; >+ >+ if (addr < type->regions[mid].base) >+ right = mid; >+ else if (addr >= (type->regions[mid].base + >+ type->regions[mid].size)) >+ left = mid + 1; >+ else { >+ *last_idx = mid; >+ return pfn; >+ } >+ } while (left < right); >+ >+ if (right == type->cnt) >+ return -1UL; >+ >+ *last_idx = right; >+ >+ return PHYS_PFN(type->regions[*last_idx].base); >+} >+#endif /*CONFIG_HAVE_ARCH_PFN_VALID*/ The same comment as Daniel, you are moving the function out of CONFIG_HAVE_MEMBLOCK_NODE_MAP. >+ > static phys_addr_t __init memblock_alloc_range_nid(phys_addr_t size, > phys_addr_t align, phys_addr_t start, > phys_addr_t end, int nid, ulong flags) >diff --git a/mm/page_alloc.c b/mm/page_alloc.c >index 2a967f7..0bb0274 100644 >--- a/mm/page_alloc.c >+++ b/mm/page_alloc.c >@@ -5459,6 +5459,7 @@ void __meminit memmap_init_zone(unsigned long size, int nid, unsigned long zone, > unsigned long end_pfn = start_pfn + size; > pg_data_t *pgdat = NODE_DATA(nid); > unsigned long pfn; >+ int idx = -1; > unsigned long nr_initialised = 0; > struct page *page; > #ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP >@@ -5490,7 +5491,7 @@ void __meminit memmap_init_zone(unsigned long size, int nid, unsigned long zone, > * end_pfn), such that we hit a valid pfn (or end_pfn) > * on our next iteration of the loop. > */ >- pfn = memblock_next_valid_pfn(pfn) - 1; >+ pfn = memblock_next_valid_pfn(pfn, &idx) - 1; > #endif > continue; > } >-- >2.7.4 -- Wei Yang Help you, Help me