Received: by 10.213.65.68 with SMTP id h4csp1902326imn; Thu, 5 Apr 2018 05:52:38 -0700 (PDT) X-Google-Smtp-Source: AIpwx49+YC1qfGRlFf5+68EciIjaBpk/RtqETaZOZ3uE4OKrE7vw3R5eQepbLOEojfM2Nh4tsEPF X-Received: by 10.99.127.21 with SMTP id a21mr1053873pgd.162.1522932758777; Thu, 05 Apr 2018 05:52:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522932758; cv=none; d=google.com; s=arc-20160816; b=GJhQC1W0fqWzgC5AOltsBq3LPAIiVbTeAlpimKbPI7V0Cm05VAtdBGPFEo2osPP1+r LspxodW3SfSc1vpUHb0ol48MWleOHG8aZX4iCdZv/S2ycYfeudMf+GEPB0iPLoxHVgKi g9sZTE8SrEvqgJg8TivgOnjCW6RLuPThfReAizGk5/T82Ivf1PZhvIHlTljwY4Vjm3Re 1ozPfbwDz54Hixuv1avOgNlvW/kA4EbM4S7IAmCWIwwoWQQrSsxsjWVh50G1btrsKbqL UfH6+dVdcW62DDhPUcgLAvG6ocPdWWtF5UOG6gRPdQdhqTFf0znJN+UB32xVVCPdh2JQ otQQ== 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:dkim-signature:arc-authentication-results; bh=Sd3jBxbkg/ejyoevLXA9TR+3kDcNCsX4RNVYQ+2mw38=; b=gfY55eGnhUll1XgkQVOWfJZqb4X6rs+sq+G2F6DQJpcWE/Ahx5bhJs97y/F9QRUc6i J+JpGb61iVj2FafGs2rCoL71ErtFHQtEP0cLN4HOLzPKL2YI0ahuB0QbdtlU4s0dVjGY 1PpPE2emiYghIxezm8uw1PvMeqiIsBsCirHoOJ/zPgbfgbMRhfHkcKjJIaQImcfyPvVV 7oynCghvNwtRO7WQVf/fsWhCXBIAwXsFErG0CMHPWKpdhVLgZYZdDz6RMu3MEAKQNt9H yOYxWAc7ljJCyq2VydOQefpouuH9o1+0JdmZgYSGsyP0DTmlk5DdFFfQlhJBTzwxIfCI i+jg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=H/H/GtNr; 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 o33-v6si5472926plb.369.2018.04.05.05.52.24; Thu, 05 Apr 2018 05:52:38 -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=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=H/H/GtNr; 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 S1751332AbeDEMvM (ORCPT + 99 others); Thu, 5 Apr 2018 08:51:12 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:37054 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751097AbeDEMvL (ORCPT ); Thu, 5 Apr 2018 08:51:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Sd3jBxbkg/ejyoevLXA9TR+3kDcNCsX4RNVYQ+2mw38=; b=H/H/GtNroCE+Ehn+o+ncoJa9I 3jIKdDwcSxPIsYsEPSxsc4iM72VE7wWek+b9vPQjI2ML1v1ve+XOG35a70rx46XD2g+xKlRPuqCzW jyTjO9FBvoUL1+3Zn6yjXoJRlY4biedsnRVoeaB4P25AmLBYgwrdR6vdjnJkeNP1Tgvn+rgvOIOgm fXq0w0pFeAvKAdAlajrO7fZ2Ys/TdfJIV/q3L+MkzAgjWavb66CZf130nKbge7O53a2VXJriewr2U IUQDZJ22mZkGtZURKPdt7ahudm6iSNoNGr4lIQxVZ9WICF6tfKcuo4XoKYWYINv3UQXDuSKH4yXfW TKjl8C+oQ==; Received: from willy by bombadil.infradead.org with local (Exim 4.90_1 #2 (Red Hat Linux)) id 1f44Lu-0008Qh-Uc; Thu, 05 Apr 2018 12:50:54 +0000 Date: Thu, 5 Apr 2018 05:50:54 -0700 From: Matthew Wilcox To: Jia He Cc: Russell King , Catalin Marinas , Will Deacon , Mark Rutland , Ard Biesheuvel , Andrew Morton , Michal Hocko , Wei Yang , Kees Cook , Laura Abbott , Vladimir Murzin , Philip Derrin , AKASHI Takahiro , James Morse , Steve Capper , Pavel Tatashin , Gioh Kim , Vlastimil Babka , Mel Gorman , Johannes Weiner , Kemi Wang , Petr Tesarik , YASUAKI ISHIMATSU , Andrey Ryabinin , Nikolay Borisov , Daniel Jordan , Daniel Vacek , Eugeniu Rosca , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Jia He Subject: Re: [PATCH v7 2/5] arm: arm64: page_alloc: reduce unnecessary binary search in memblock_next_valid_pfn() Message-ID: <20180405125054.GC2647@bombadil.infradead.org> References: <1522915478-5044-1-git-send-email-hejianet@gmail.com> <1522915478-5044-3-git-send-email-hejianet@gmail.com> <20180405113444.GB2647@bombadil.infradead.org> <1f809296-e88d-1090-0027-890782b91d6e@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1f809296-e88d-1090-0027-890782b91d6e@gmail.com> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 05, 2018 at 08:44:12PM +0800, Jia He wrote: > > > On 4/5/2018 7:34 PM, Matthew Wilcox Wrote: > > On Thu, Apr 05, 2018 at 01:04:35AM -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. > > Sure, but I bet if we are >end_pfn, we're almost certainly going to the > > start_pfn of the next block, so why not test that as well? > > > > > + /* fast path, return pfn+1 if next pfn is in the same region */ > > > + if (early_region_idx != -1) { > > > + start_pfn = PFN_DOWN(regions[early_region_idx].base); > > > + end_pfn = PFN_DOWN(regions[early_region_idx].base + > > > + regions[early_region_idx].size); > > > + > > > + if (pfn >= start_pfn && pfn < end_pfn) > > > + return pfn; > > early_region_idx++; > > start_pfn = PFN_DOWN(regions[early_region_idx].base); > > if (pfn >= end_pfn && pfn <= start_pfn) > > return start_pfn; > Thanks, thus the binary search in next step can be discarded? I don't know all the circumstances in which this is called. Maybe a linear search with memo is more appropriate than a binary search.