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 777C7C46CD2 for ; Tue, 23 Jan 2024 03:33:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DE37A6B0075; Mon, 22 Jan 2024 22:33:17 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D93B66B007B; Mon, 22 Jan 2024 22:33:17 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C5AFC6B0083; Mon, 22 Jan 2024 22:33:17 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id B38326B0075 for ; Mon, 22 Jan 2024 22:33:17 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 1AD23804A4 for ; Tue, 23 Jan 2024 03:33:17 +0000 (UTC) X-FDA: 81709155234.11.0606A05 Received: from out-178.mta1.migadu.com (out-178.mta1.migadu.com [95.215.58.178]) by imf17.hostedemail.com (Postfix) with ESMTP id 2B41040006 for ; Tue, 23 Jan 2024 03:33:14 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=hDdILOnH; spf=pass (imf17.hostedemail.com: domain of muchun.song@linux.dev designates 95.215.58.178 as permitted sender) smtp.mailfrom=muchun.song@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705980795; 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=dGyLFiCSPKnOgt2WMLCtOYKgq5Jt8mMSuChCnDpw3sE=; b=RZa5G0WxUkSqaXB+H78Z5Q7WYPIJzakBKZqKBbTO9ETp1aJEipdMbkcrouRWVHyqibaZZO w7/IsAAb3fqNw5FboRmii+MjmYJrp36zjYP11ir1+38QCSDpQReWJm7DkGLtMOF6UyX1wF 9b7CJ/W5bxwSOjwe+5PKrwg8lA7vfaQ= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705980795; a=rsa-sha256; cv=none; b=KvYOOnL/D7ZwEOH8HEFYCxe9gEjlHkjhPka/Zc9ABmx1q7UIg89Cl5TOiqm+zeJwyBsWGB 7Y8JmqdxH+KPXyYMOcMCNi9lYOrhrTEzvdj6hWyjryO51+E7KJe4VxHJvUE4KNn9k9Zl1w /G0zGKyTFewVCnjd4kjA2u+SL6itF3k= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=hDdILOnH; spf=pass (imf17.hostedemail.com: domain of muchun.song@linux.dev designates 95.215.58.178 as permitted sender) smtp.mailfrom=muchun.song@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Content-Type: text/plain; charset=us-ascii DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1705980793; 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=dGyLFiCSPKnOgt2WMLCtOYKgq5Jt8mMSuChCnDpw3sE=; b=hDdILOnHa8NAGzybj5naIfs7XhsW6yGVUI0mLp3wSur97OZeZCcTf+GNMtuTZh9YvMngVg jH6zVoGsuSW/BEOdpXQ62XSPAsc29ZSZAoayO48d+pFWjEx09xuqfulfmjMrTs6gFDJW82 zNGhPQjLUXBQ+TnbaAac7FitvyZV7dE= Mime-Version: 1.0 Subject: Re: [PATCH v4 6/7] hugetlb: parallelize 2M hugetlb allocation and initialization X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Muchun Song In-Reply-To: <829fb129-f643-4960-a2da-cd38e5ee8f39@linux.dev> Date: Tue, 23 Jan 2024 11:32:28 +0800 Cc: David Hildenbrand , David Rientjes , Mike Kravetz , Andrew Morton , Tim Chen , Linux-MM , LKML , Gang Li Content-Transfer-Encoding: quoted-printable Message-Id: References: <20240118123911.88833-1-gang.li@linux.dev> <20240118123911.88833-7-gang.li@linux.dev> <14e38e95-2bc6-4571-b502-4e3954b4bcc4@linux.dev> <849D7EA4-BCF4-4587-8A78-F3B35B63EAE9@linux.dev> <829fb129-f643-4960-a2da-cd38e5ee8f39@linux.dev> To: Gang Li X-Migadu-Flow: FLOW_OUT X-Stat-Signature: 4kfjergwx71i7qj57ex61t9yraagm3at X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 2B41040006 X-Rspam-User: X-HE-Tag: 1705980794-849933 X-HE-Meta: U2FsdGVkX1+2+CjUcvHvq9Y2TwFnKVV8GLJlJsGLM5XxV447cbDgvI/vFgBK+iZemr+TGfAwKlYV8kB1vERWKXcb0KAni3hnmVvoLGwz1mKZmZh7/ZhOkntRd0m60Tn7+foephas8vmIZqYyhPV49VpTKDundQxm86z+il3GoFDCAjkwBPVGUXKHc6g362C1rESWvovP/+FOHItimwzrpB1DRp42eXUiVrYTdeGAFcmhghZmEelB0VGDeQk9ihBRP0UKUeR+MdldnB+SrYZ8dmZl6djnF3SYsP5K/eQi82tkgFC/2yfjymjyNs+wGdjtR7kEc3kjqy36fbfV1rBRVaR3iI5K7v/JLDNTVhmyJoyxAo/QTfK4iKYNtONQt2xlOwLIh7i6LjmxK4POROmJVoJUg+RHcLBE54T4CNJPNDrWeP+pSxZ05Tgk95nXfo9M+XsWXqJKKj7P3z+5+/rErsrmIgcaPvqQ5nu5M2pzdvTsGNcVU7MGHQW0A6xmTVskZODebCW19BQGNz3ou39aLEMtF6CbDT21ScW9a8qJBGty2/zoMKm5bT6gxc7a7drk+usbeMKK/XXp/s8LMBrbea0//19g0p53LAg3gN4txD7qT9ijjcq3kmPihvvrNFyAwgXruy/3dzMf3jcuzuOZWuR7AGlojmZr60+qcBUwVpPdMrIOpSwMEYgXE8mbjrktmLBWLOmLyvRYzkCa8Wr2B9e7oztkX07KmNTXKctDMlh9jRIlRL0U4eaR5axt2RSJSeQ1CH/6+UA4PGvBQd82eOGp72e0K4ixeI8vD57XVEg6k3iKShQ1pprF6I12p3zScbcRcqh2CReA9Q0a4ZZ0XIrf0IQ/DY/ntxWecgrIh5PWpqq0HpxX/tFCoZaKSXuIOzgw98lNHErzXNLuTJDn6hSxdrM7il333aBo55yh006LgzoV/LnR4VO21sZhgepGpLEH3bSPEKAv2sx0/fF lxosyP9z guspVf1pXJrZ27H2ifJkVIUNduY/9EJQOFHzdi06kLEr5M7XdSjArVmuquMPURZjI0Jm2i+gBZFq1gbKbL0AjJT6Xshnaqde9OpL4E8Alm1YXrtE= 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: List-Subscribe: List-Unsubscribe: > On Jan 23, 2024, at 10:12, Gang Li wrote: >=20 > On 2024/1/22 19:30, Muchun Song wrote: >>> On Jan 22, 2024, at 18:12, Gang Li wrote: >>>=20 >>> On 2024/1/22 15:10, Muchun Song wrote:> On 2024/1/18 20:39, Gang Li = wrote: >>>>> +static void __init hugetlb_alloc_node(unsigned long start, = unsigned long end, void *arg) >>>>> { >>>>> - unsigned long i; >>>>> + struct hstate *h =3D (struct hstate *)arg; >>>>> + int i, num =3D end - start; >>>>> + nodemask_t node_alloc_noretry; >>>>> + unsigned long flags; >>>>> + int next_node =3D 0; >>>> This should be first_online_node which may be not zero. >>>=20 >>> That's right. Thanks! >>>=20 >>>>> - for (i =3D 0; i < h->max_huge_pages; ++i) { >>>>> - if (!alloc_bootmem_huge_page(h, NUMA_NO_NODE)) >>>>> + /* Bit mask controlling how hard we retry per-node = allocations.*/ >>>>> + nodes_clear(node_alloc_noretry); >>>>> + >>>>> + for (i =3D 0; i < num; ++i) { >>>>> + struct folio *folio =3D alloc_pool_huge_folio(h, = &node_states[N_MEMORY], >>>>> + &node_alloc_noretry, &next_node); >>>>> + if (!folio) >>>>> break; >>>>> + spin_lock_irqsave(&hugetlb_lock, flags); >>>>> I suspect there will more contention on this lock when = parallelizing. >>>=20 >>> In the worst case, there are only 'numa node number' of threads in >>> contention. And in my testing, it doesn't degrade performance, but >>> rather improves performance due to the reduced granularity. >> So, the performance does not change if you move the lock out of >> loop? >>=20 >=20 > If we move the lock out of loop, then multi-threading becomes = single-threading, which definitely reduces performance. No. I mean batching the pages into pool list just like = prep_and_add_allocated_folios does. >=20 > ``` > + spin_lock_irqsave(&hugetlb_lock, flags); > for (i =3D 0; i < num; ++i) { > struct folio *folio =3D alloc_pool_huge_folio(h, = &node_states[N_MEMORY], > &node_alloc_noretry, = &next_node); > if (!folio) > break; > - spin_lock_irqsave(&hugetlb_lock, flags); > __prep_account_new_huge_page(h, folio_nid(folio)); > enqueue_hugetlb_folio(h, folio); > - spin_unlock_irqrestore(&hugetlb_lock, flags); > cond_resched(); > } > + spin_unlock_irqrestore(&hugetlb_lock, flags); > } > ```