Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp8353517ybi; Tue, 23 Jul 2019 07:10:13 -0700 (PDT) X-Google-Smtp-Source: APXvYqzl/6cHNXgj154VIskC6W3hEqBWEb7pEJYecz6gaA0h1fsncEEGYpHykoh4UrJNn8ZHpTaX X-Received: by 2002:a17:902:9a06:: with SMTP id v6mr78790858plp.71.1563891013590; Tue, 23 Jul 2019 07:10:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563891013; cv=none; d=google.com; s=arc-20160816; b=kQ9rw1gz2WZ1yTdMViTENVd/MSNjV0xwwf91VV9VEYZTcLIFy+meomG4ZOe6unPGNI aqKsxXZh+z3i1H5/tMHT/YwbQgV0yFVWsiu9EudBr0L2dXvYywYjy3qXY/330FHPkAwa /eC7qGzZ3P8sZSojYR7CgmjPfI3BR0tRIxTdxS2/PD5wARkOTwntuh767IFmsEgEFB/9 Fpje4RVLdvrwM+Ec2v2SyEZ+IyRFNw2UKnbReUtTs4x/tc7Fl1vsO34Q/aEAc5LLSRZh R2z3V83bY44S3g5t1HHeRaUQ66QTFmx7Jb/jIGWy18RL96R7EURGtmExqDMQpDmYjygK XWdQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:subject:cc :to:from; bh=Y/zml0Bmqj+dMrviRHdA161MJMflzVlVIfgMq4IsxGM=; b=NuHhTIQ0LyoBIX5GyCR1TOisMrZPndTQVuv8bI1oGbp46qmMxcZVtA3Q79SAj7J+WW LB9qAg4cjWgoBKNU2mUOawRFlUSY8LTtCst/X62JCfnob4dS65fSaWnDniKOaGcU6JVE uDfaUThwCVp4cgNV+916jHTkEcLNkivSv+4NZKVsre3fVV+wll7BYDgxQXoeOVtfSFde QcjGBFtr07HoVLs0R1aUC0ZqcqbKDXpAaEw/wvFyI3aOqHQisGWOz+LSt2oHoQ3gmpBj t/beId8C1McMb9Fblxi1CCTKTkQxpKM5vztBwOYpSvcMrlZLZ91f9i9GWF6uGU8b2f/s VAyA== 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 q11si11571897pls.424.2019.07.23.07.09.57; Tue, 23 Jul 2019 07:10:13 -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 S1732418AbfGWFxw (ORCPT + 99 others); Tue, 23 Jul 2019 01:53:52 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:2699 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1732295AbfGWFxw (ORCPT ); Tue, 23 Jul 2019 01:53:52 -0400 Received: from DGGEMS414-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id D4A5E6E6D5A9386D9C48; Tue, 23 Jul 2019 13:53:49 +0800 (CST) Received: from linux-ibm.site (10.175.102.37) by DGGEMS414-HUB.china.huawei.com (10.3.19.214) with Microsoft SMTP Server id 14.3.439.0; Tue, 23 Jul 2019 13:53:42 +0800 From: Hanjun Guo To: Ard Biesheuvel , Andrew Morton , Catalin Marinas , "Jia He" , Mike Rapoport , Will Deacon CC: , , , Hanjun Guo Subject: [PATCH v12 0/2] introduce memblock_next_valid_pfn() (again) for arm64 Date: Tue, 23 Jul 2019 13:51:11 +0800 Message-ID: <1563861073-47071-1-git-send-email-guohanjun@huawei.com> X-Mailer: git-send-email 1.7.12.4 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.175.102.37] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Here is new version of "[PATCH v11 0/3] remain and optimize memblock_next_valid_pfn on arm and arm64" from Jia He, which is suggested by Ard to respin this patch set [1]. In the new version, I squashed patch 1/3 and patch 2/3 in v11 into one patch, fixed a bug for possible out of bound accessing the regions, and just introduce memblock_next_valid_pfn() for arm64 only as I don't have a arm32 platform to test. Ard asked to "with the new data points added for documentation, and crystal clear about how the meaning of PFN validity differs between ARM and other architectures, and why the assumptions that the optimization is based on are guaranteed to hold", to be honest, I didn't see PFN validity differs between ARM and x86 architecture, but there is a bug in commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns where possible") which has a possible out of bound accessing the regions as well, so not sure that is the root cause. Testing on a HiSilicon ARM64 server (a 4 sockets system), I can get pretty much speedup for bootmem_init() at boot: with 384G memory, before: 13310ms after: 1415ms with 1T memory, before: 20s after: 2s [1]: https://lkml.org/lkml/2019/6/10/412 Jia He (2): mm: page_alloc: introduce memblock_next_valid_pfn() (again) for arm64 mm: page_alloc: reduce unnecessary binary search in memblock_next_valid_pfn arch/arm64/Kconfig | 1 + include/linux/mmzone.h | 9 +++++++ mm/Kconfig | 3 +++ mm/memblock.c | 56 ++++++++++++++++++++++++++++++++++++++++++ mm/page_alloc.c | 4 ++- 5 files changed, 72 insertions(+), 1 deletion(-) -- 2.19.1