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 D112FC4725D for ; Mon, 22 Jan 2024 11:31:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C7C4C6B007D; Mon, 22 Jan 2024 06:31:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C04C36B007E; Mon, 22 Jan 2024 06:31:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A7EAE6B0080; Mon, 22 Jan 2024 06:31:27 -0500 (EST) 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 916746B007D for ; Mon, 22 Jan 2024 06:31:27 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 39A4E1C127E for ; Mon, 22 Jan 2024 11:31:27 +0000 (UTC) X-FDA: 81706731414.09.92B39DC Received: from out-176.mta1.migadu.com (out-176.mta1.migadu.com [95.215.58.176]) by imf09.hostedemail.com (Postfix) with ESMTP id 5FAE1140013 for ; Mon, 22 Jan 2024 11:31:25 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=PMEggpjE; spf=pass (imf09.hostedemail.com: domain of muchun.song@linux.dev designates 95.215.58.176 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=1705923085; 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=W4RSY4mP4w+4iqUvb0NCuJ+3jjeweVzC37FLV3OpmyE=; b=k1mjaluztnyE8oOlJa8WZvaKgb8wzI/48dnymjtwAY5suL4AiA58XaPIs2UHO0EIo3YgNx y4lcDJ4jto3+mPJloF6qSR6VT1iXaQMGmKZFwi8YvtcKtH7Y1bb1iA6tFDUgenUpxzaDmJ OEL9QLwK459ahXHBBG9y1W7v1jrmZD0= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=PMEggpjE; spf=pass (imf09.hostedemail.com: domain of muchun.song@linux.dev designates 95.215.58.176 as permitted sender) smtp.mailfrom=muchun.song@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705923085; a=rsa-sha256; cv=none; b=E9sJRORXAQAfE2EfXNMuwbGntM66B9vkAE62ZCvHDfGTNuKFVzukM0FlEGgTimx6tU0Ikj XAEx1j00Fbm9gGe1BB84Pc/wEtoV+QgjPN4SvaaFtvjvuHjtADU/tDDeBKiGEl8NFsrzz8 Db6+H1d8lwWe+B+Jhhegy4PYFlfY9Hc= Content-Type: text/plain; charset=us-ascii DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1705923083; 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=W4RSY4mP4w+4iqUvb0NCuJ+3jjeweVzC37FLV3OpmyE=; b=PMEggpjEinAWwbzcD5dsOZTBv+LWhJWHnECOalXLXbkco2R5QUmojHUGekv7iVGWCNdlqJ 1iokj5dqbZHDfE82iyZcqQ1BH/iID1dNGsBM/Kg6MD+/NJT/7I2kgWfpTiiDj0cViSHQs5 JgDKLshkJryYN29JnEWUDaj5dkfRdBs= 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: <14e38e95-2bc6-4571-b502-4e3954b4bcc4@linux.dev> Date: Mon, 22 Jan 2024 19:30:39 +0800 Cc: David Hildenbrand , David Rientjes , Mike Kravetz , Andrew Morton , Tim Chen , Linux-MM , LKML , ligang.bdlg@bytedance.com Content-Transfer-Encoding: quoted-printable Message-Id: <849D7EA4-BCF4-4587-8A78-F3B35B63EAE9@linux.dev> References: <20240118123911.88833-1-gang.li@linux.dev> <20240118123911.88833-7-gang.li@linux.dev> <14e38e95-2bc6-4571-b502-4e3954b4bcc4@linux.dev> To: Gang Li X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: 5FAE1140013 X-Rspam-User: X-Stat-Signature: 549zfqsy55atp1a93ubjprbtj7pi4js9 X-Rspamd-Server: rspam01 X-HE-Tag: 1705923085-933084 X-HE-Meta: U2FsdGVkX18TI7suU8VKtbIEqApDglOS+sxiR4SnHPxgYgenMARuixRziN7ShqAhCIhv01CWQcDDla5vRB1b+5KRNMidmSRLjvrLc8furQOAqQlmXd9F5MBEqmzIORX376cQOTSAoFNleNcVEy3s33yAQIaRUB5zyrrJruCKnN4P8IIvCisLWB3t9Xc+0ocXdXMZfHyUtn9xtuZOncd7e1uEQAh423niNIzFgairtXNK2LHa8mtdPs/SxLOOtxdgwBqAoRQQ8xbLXjrVZHiR09hLdwhlJwlC8AXTWV+900cAHFHPAbpn/1o1PVA4yCChOmn/J79VwofmEZlwVhzD2l3OwGEOlaiAh/qQjLKBDVUV1r1hTJRSj9uaaGfoGwSjQ9dudEElVWme9rpR6dJTVVr7SRfQB8p1Avw2iNdoPDhmVMu7s95LjnByxZGxAIf0w9rCnRRP+NWWewUJCPKino2qNtmezZYrcCkfjjIhR8RhiiNkHLhOkYUyPsWKABoa7AMW5A6G1XyHORsKhiUMSdD2YI8AFxdLYnhjB4/XNLtObaPvN1k+1ekRZQZf/FgV7C/3fb+xmdoVrUS3I71ZgA3JjvoHF+vAJkP1ffk4Tqv//81a906mm01KoznhmOeHAe92TB1Tr3eg4MCEGY9ZYseJAehiID0lCgI+Ju2HBgTwITTI7a3AFjkadTRwBlHLAMSph4sHVt4W3z87QWdlC9Fjd6SXEPfkO64t4NamyR/hW/j8moUz9NGcFQvAUcT49l1XAT0qoTgqL3DTrgONuYwVhsCIDfPiEPTb8f81QQa8lmkvPTacv622faRPjIebV2u976MD026697ydAMD1lugNyX9MDGlAWVcXSj0SitT3zBYO3PYXL+ckNQK7IDzmGy33giDqYic5868wNckH7HOerWYdsaIDieIenm0mRGzqgW1FpUrJYBOrJoEp8w6gZls7ElenkSsxDMj3Axn uPZdayQC H84UbqUbsHnoO8PL9/h/YejsP4MBWql29bvnxok0yaGOtF5CwumA11r4yKzEpvvKEm2kwKKp4HM1ZiN05kqu+2vgBQ+5YUwJ6Ux2WLZuisu0EoSwFjT9W7XvoSA== 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 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 >> I want to know why you chose to drop prep_and_add_allocated_folios() >> call in the original hugetlb_pages_alloc_boot()? >=20 > Splitting him to parallelize hugetlb_vmemmap_optimize_folios. Unfortunately, HVO should be enabled before pages go to the pool list. >=20 >>> +static unsigned long __init hugetlb_pages_alloc_boot(struct hstate = *h) >>> +{ >>> + struct padata_mt_job job =3D { >>> + .fn_arg =3D h, >>> + .align =3D 1, >>> + .numa_aware =3D true >>> + }; >>> + >>> + job.thread_fn =3D hugetlb_alloc_node; >>> + job.start =3D 0; >>> + job.size =3D h->max_huge_pages; >>> + job.min_chunk =3D h->max_huge_pages / = num_node_state(N_MEMORY) / 2; >>> + job.max_threads =3D num_node_state(N_MEMORY) * 2; >> I am curious the magic number of 2 used in assignments of ->min_chunk >> and ->max_threads, does it from your experiment? I thinke it should >> be a comment here. >=20 > This is tested and I can perform more detailed tests and provide data. >=20 >> And I am also sceptical about the optimization for a small amount of >> allocation of hugepages. Given 4 hugepags needed to be allocated on = UMA >> system, job.min_chunk will be 2, job.max_threads will be 2. Then, 2 >> workers will be scheduled, however each worker will just allocate 2 = pages, >> how much the cost of scheduling? What if allocate 4 pages in single >> worker? Do you have any numbers on parallelism vs non-parallelism in >> a small allocation case? If we cannot gain from this case, I think we = shold >> assign a reasonable value to ->min_chunk based on experiment. >> Thanks. >>=20 >=20 > That's a good suggestion, I'll run some tests and choose the best > values. >=20 >=20