From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id C17BDEB8FDB for ; Wed, 6 Sep 2023 14:33:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 320AF28001B; Wed, 6 Sep 2023 10:33:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2D0D1280017; Wed, 6 Sep 2023 10:33:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1995828001B; Wed, 6 Sep 2023 10:33:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 0815B280017 for ; Wed, 6 Sep 2023 10:33:19 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id CEACD1204D4 for ; Wed, 6 Sep 2023 14:33:18 +0000 (UTC) X-FDA: 81206415276.19.791C81A Received: from out-215.mta0.migadu.com (out-215.mta0.migadu.com [91.218.175.215]) by imf11.hostedemail.com (Postfix) with ESMTP id D18A040016 for ; Wed, 6 Sep 2023 14:33:16 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=HiBzoVzV; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf11.hostedemail.com: domain of muchun.song@linux.dev designates 91.218.175.215 as permitted sender) smtp.mailfrom=muchun.song@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1694010797; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=hRnsZjMoWhfGvrdhR05GA1VO49xhRVfGQf836ZBTsLE=; b=joJNM2rxCuggbtF5Fg33fkKgPF2XHOBccXbjzXXYTdCQ12wVtoayzkcJMM0PFGuYQLi0VE bRHQYYPg/QQgwSrS4RaMsf7cApWciAAtVc5GJHjP+9wiOOgl8hR8bd55qmVdRpf2CCvavt JU7kPbQ6sLWylk9Asg8VqrrI/nJfBjI= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=HiBzoVzV; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf11.hostedemail.com: domain of muchun.song@linux.dev designates 91.218.175.215 as permitted sender) smtp.mailfrom=muchun.song@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694010797; a=rsa-sha256; cv=none; b=YUjlMaLM0N85qRrj7KiVro0ECUWZkoGc8MsC3/J8zx1DZ6NDk4FncGHrK09alo/ktJ34/9 zL7CVLlXxEKtGg1gSoyh0GPIRH7xh1lBL3yTEUth175Vz8s9fj7RCp8CKAwqyKaoyQ7aN9 MPsl7lYRWR3l0WlqBsxK0pdyS4hYzQI= Content-Type: text/plain; charset=us-ascii DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1694010794; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=hRnsZjMoWhfGvrdhR05GA1VO49xhRVfGQf836ZBTsLE=; b=HiBzoVzVyIqnPgCaejFQGJ/2re3LK/EPEpMWCZZfU8N26qzeXkB68JKdLVR27jgXzH9gsC 8FYxPXX5DBo4hYTzLNTYpH4mGkezCbwrmD61sEIxjwpHMOCCl7LUVDCv5YcaLm9Acsz9gV 7n/YiE++fXZEUNDrvdkdHNRIoZDgicM= Mime-Version: 1.0 Subject: Re: [PATCH resend] mm: hugetlb_vmemmap: use bulk allocator in alloc_vmemmap_page_list() X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Muchun Song In-Reply-To: Date: Wed, 6 Sep 2023 22:32:35 +0800 Cc: Matthew Wilcox , Andrew Morton , Mike Kravetz , Linux-MM , Yuan Can Content-Transfer-Encoding: quoted-printable Message-Id: <11F83276-0C5C-4526-85F7-C807D741EAFD@linux.dev> References: <20230905103508.2996474-1-wangkefeng.wang@huawei.com> <4029895B-26D8-4FA7-9E1A-2452B1C71130@linux.dev> To: Kefeng Wang X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: D18A040016 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: z5w1iwaqi9spgrtojurttxw19wesafm1 X-HE-Tag: 1694010796-954701 X-HE-Meta: U2FsdGVkX1/DjxH40dg9dfxAy2ILKlZh/RqMNYNBdIktR5RetxnmxySMGUHg/8lqG2qrsIdGmaKLIBtA85NrN0BKe93oBFJtwjAqC/ybNlyF3Tqwna8gULRdADUM+5o3vtqyQt89MqwVSgmuUlLvnZenYBh6SOITp3pMGTRhOulOKPC0M0enCrwlfxAlHzJcNNM79uRAfOLL/0C0DyPNeKAjkTGCTklyzyJQtL1nByQNxbzHzsf0GxTGKAcH8Xj26wAgQQ/BRAEfcTVGTUkul3dlGrfL+LflIhetWXic+sBoXYs+vWepBi/y42vPnC1lVc7QZS/M2b2ugEkIE51pjZuS8/vYtNAA70D6mESha60BjmQAfxxFwKwaklxK+wUQjw70QvwUNYyc1YmeeyekACCYOenSRU+gD9x/qTZGwsGLo7VieK+mLGWZksV7HhlyMOp5rZO61+T17VgQWTKkTNGlgllq+jcvbErAmgbxaVNo1UGf+osl7B2q9dhTnUZSYGY2cYkiGU4JMRZGtf40ccDzX95GTcMg07x2+UbUdShPsSmTYcJYSFhFwtVgll3vb5TqU7T7LHwnARhGdWvY3dTOLQYczSf0SP3hij8aqFRe3l1t/QJe7aUfH2j8+Kwn9e1iTsYXw/cgfGi89EazZSVUgDBTBfrt33GxWpCpL/Sf6PDTMKAsU/pdJ870l8UkL7Fj3sK9bO8px7Lj+6oPLZ3dz07YWU6qJZgZiOVkVMTo2jKx8z3QnZY15NQKVtVi/Ndp/6kVYOsU5tfOz/9VWByoQhUr2ps/+cw+UGXkq9XwNq6KauxBWL5CDYYEAe5JtEhvhT2Utn+9tW/HyIghqAAaH8a7ui88BtnCNeoz9MyGV4U5GPlrsZYNffNCARKKYC5B3JLdPYHg9/h98SAdwVChoUOGO2RhDoauQhyos1bx/YFMfkx1By+gMhMhiXhjoGfeWm90LtHUL9Wr3Pq SdJjHReU Esx6l4GnvXMfxXIoOq9a5sNJqaNXVYtu5mUIjjP8FtM9DGQjuv5SAIAEYAgOcqwtwhU3O8HS2MRxKccNzyXtyx054gxkXXC88us/+cwl4bTVayYqCM9hQcQLO01fv2dhc+2xfgmH96mVD4oEbxUn6JbNsoZubF71QUr8sVIYexImSLLCDUXhxwzVn2w== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: > On Sep 6, 2023, at 17:33, Kefeng Wang = wrote: >=20 >=20 >=20 > On 2023/9/6 11:25, Muchun Song wrote: >>> On Sep 6, 2023, at 11:13, Kefeng Wang = wrote: >>>=20 >>>=20 >>>=20 >>> On 2023/9/6 10:47, Matthew Wilcox wrote: >>>> On Tue, Sep 05, 2023 at 06:35:08PM +0800, Kefeng Wang wrote: >>>>> It is needed 4095 pages(1G) or 7 pages(2M) to be allocated once in >>>>> alloc_vmemmap_page_list(), so let's add a bulk allocator varietas >>>>> alloc_pages_bulk_list_node() and switch alloc_vmemmap_page_list() >>>>> to use it to accelerate page allocation. >>>> Argh, no, please don't do this. >>>> Iterating a linked list is _expensive_. It is about 10x quicker to >>>> iterate an array than a linked list. Adding the list_head option >>>> to __alloc_pages_bulk() was a colossal mistake. Don't perpetuate = it. >>>> These pages are going into an array anyway. Don't put them on a = list >>>> first. >>>=20 >>> struct vmemmap_remap_walk - walk vmemmap page table >>>=20 >>> * @vmemmap_pages: the list head of the vmemmap pages that can be = freed >>> * or is mapped from. >>>=20 >>> At present, the struct vmemmap_remap_walk use a list for vmemmap = page table walk, so do you mean we need change vmemmap_pages from a list = to a array firstly and then use array bulk api, even kill list bulk api = ? >> It'll be a little complex for hugetlb_vmemmap. Should it be = reasonable to >> directly use __alloc_pages_bulk in hugetlb_vmemmap itself? >=20 >=20 > We could use alloc_pages_bulk_array_node() here without introduce a = new > alloc_pages_bulk_list_node(), only focus on accelerate page allocation > for now. >=20 No. Using alloc_pages_bulk_array_node() will add more complexity (you = need to allocate an array fist) for hugetlb_vmemap and this path that you optimized is = only a control path and this optimization is at the millisecond level. So I don't think = it is a great value to do this. Thanks.