Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp9296169ybi; Wed, 24 Jul 2019 01:35:16 -0700 (PDT) X-Google-Smtp-Source: APXvYqxoFs9qWGITiwbKA02TvucSKRV/Ny7dfIKk42bcEDGriznk4MSvZCXeOSzIKtUjD5+/Y1mu X-Received: by 2002:a63:9e56:: with SMTP id r22mr23481923pgo.221.1563957316537; Wed, 24 Jul 2019 01:35:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563957316; cv=none; d=google.com; s=arc-20160816; b=yjb0RgQ0Ka/5iA6OLJ5E7GNOoux58elgcSamjujVoEkmQKMG8sHc5XXBIvwAiMSPlV omO2VeB+3QDKD6WUwtzBuuwJemaFJGhfhX7dX4VIWE0S/3bH9ikoCzMuGj1Wu4ys4D2p 72TmC0kiRHRRZgy0lUoYnhWNdenXh5PI5TJc0/uBqVEI3t4UIIZbl6XlLHkxDR74APha NA7Srr8+4aq/lakBHNMF9Zk/jeyr8R9VAW7f9GHY3PtSCtHzsGcrAzUKPYLEowE0933o G/e0dKJbueY3SYyj9zRkeyQEhGt/fT2qDRlBJ/DqptG4Bz5RKM24IVbQJGtDyddEMqoe 4ZOA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=oitnFF/InWTMHJQSUazp84sh4LWSF8vLTtJQZuvirlk=; b=Sdlzh8RPmaM0BgX6JyODh7xj9ZkzXjjMLDLO44itedAtfLqckbWR9jAFoLWF4/CsLw V0i5CqmK4vYATtieI62mV9jhagiP5ikEULfI8oA6bg6TjkFpu9d3VQfcu6Qfs3AX7s5C 7Oi6xt8JOWiu0VZYbrBjS8/EnIdJMDIgBYHgkcr3Hq+nkjzx3rDejyu7MAZ/WDxzARBR eEtreXTg8ohljovoZsJyqAlFe+5l65XFG2XMUd59+ZSWMtBNTTpQ6ys56ur8KK/ckz88 NOxkni2zQbriMLYi8VSRJYgbOiDMppldOQbGWlz9YUMb0c7nqdoc6FOJ/5WtTrgO5bO9 3wOg== 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 d36si12514425pla.113.2019.07.24.01.35.01; Wed, 24 Jul 2019 01:35:16 -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; 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 S1726492AbfGXIdV (ORCPT + 99 others); Wed, 24 Jul 2019 04:33:21 -0400 Received: from szxga07-in.huawei.com ([45.249.212.35]:54244 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725870AbfGXIdU (ORCPT ); Wed, 24 Jul 2019 04:33:20 -0400 Received: from DGGEMS403-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id D5579585EAE5EF849C02; Wed, 24 Jul 2019 16:33:18 +0800 (CST) Received: from [127.0.0.1] (10.177.223.23) by DGGEMS403-HUB.china.huawei.com (10.3.19.203) with Microsoft SMTP Server id 14.3.439.0; Wed, 24 Jul 2019 16:33:16 +0800 Subject: Re: [PATCH v12 2/2] mm: page_alloc: reduce unnecessary binary search in memblock_next_valid_pfn To: Mike Rapoport CC: Ard Biesheuvel , Catalin Marinas , , , Jia He , Andrew Morton , Will Deacon , References: <1563861073-47071-1-git-send-email-guohanjun@huawei.com> <1563861073-47071-3-git-send-email-guohanjun@huawei.com> <20190723083353.GC4896@rapoport-lnx> From: Hanjun Guo Message-ID: <868f90c7-a728-9eb3-7529-f5a8a501a76a@huawei.com> Date: Wed, 24 Jul 2019 16:33:01 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20190723083353.GC4896@rapoport-lnx> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.223.23] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019/7/23 16:33, Mike Rapoport wrote: > On Tue, Jul 23, 2019 at 01:51:13PM +0800, Hanjun Guo wrote: >> From: Jia He >> >> After skipping some invalid pfns in memmap_init_zone(), 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. >> >> Furthermore, if the pfn is in a gap of two memory region, skip to next >> region directly to speedup the binary search. > How much speed up do you see with this improvements relatively to simple > binary search in memblock_next_valid_pfn()? The major speedup on my platform is the previous patch in this patch set, not this one, I think it's related to sparse memory mode for different platforms. Thanks Hanjun >