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 1D0B0C4706C for ; Fri, 12 Jan 2024 08:08:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A41738D0005; Fri, 12 Jan 2024 03:08:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9EFD98D0001; Fri, 12 Jan 2024 03:08:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 891AF8D0005; Fri, 12 Jan 2024 03:08:25 -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 765A18D0001 for ; Fri, 12 Jan 2024 03:08:25 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 3EBF8140D8A for ; Fri, 12 Jan 2024 08:08:25 +0000 (UTC) X-FDA: 81669931770.16.D2E4BB4 Received: from out-173.mta0.migadu.com (out-173.mta0.migadu.com [91.218.175.173]) by imf27.hostedemail.com (Postfix) with ESMTP id 3BF2340010 for ; Fri, 12 Jan 2024 08:08:22 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=j3rSbpLE; spf=pass (imf27.hostedemail.com: domain of gang.li@linux.dev designates 91.218.175.173 as permitted sender) smtp.mailfrom=gang.li@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=1705046903; 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=bHHljA0oQNzdAwnrcBdcmTqIurHhJV7HJIprweZM2NI=; b=5Tf5nSBTiimhvuzT8JjOMz068e/mO6EIYNoXYjyO1HZUYw0V0hYgrpMtfohIgLDCpZY0Hn oW+UFchElAHE0y5TnSiiejcdJGpj3ebtNiX+zkHahXbVaJm5P0x6nM/U79cEclS/qonbIA 4E6V9k1gIKAOU7r1uguHYv1LveryeeM= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=j3rSbpLE; spf=pass (imf27.hostedemail.com: domain of gang.li@linux.dev designates 91.218.175.173 as permitted sender) smtp.mailfrom=gang.li@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705046903; a=rsa-sha256; cv=none; b=svMt77G4xwXJZneYmhMQozr7nTcluZFEHEIHpSjWzeUOFgZZmHn6US9LH0Uaf/Q3KVvTvB g8uLD+XIU97baoGUiQ+zsPmeev7HPWRzNYdD/z2dtjN+yBorU/SDn86bcDcH5NjbkR9l0w N9C9z3M/FgQOprDZQXvuo7mePj5DN3s= Message-ID: <2296235e-b15a-445d-b867-125c6d85a8a6@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1705046901; 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=bHHljA0oQNzdAwnrcBdcmTqIurHhJV7HJIprweZM2NI=; b=j3rSbpLE9NGNOEkTBHFouF0sqQj4U/xScJxrT07bH6resfKDDYy7dboO6ZV8Vx5HTTKPfI WRZ8EJOTNRBnOi4DqRNNw3MvwQyQfzHUxG/qfZlx8Auhe2M0c/uQhJmODfzN1o8SinNCWy W9yWQMtlJYpL/Zoykz3sxthJsA8uYa8= Date: Fri, 12 Jan 2024 16:07:54 +0800 MIME-Version: 1.0 Subject: Re: [PATCH v3 4/7] hugetlb: pass *next_nid_to_alloc directly to for_each_node_mask_to_alloc Content-Language: en-US To: Tim Chen , David Hildenbrand , David Rientjes , Mike Kravetz , Muchun Song , Andrew Morton Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, ligang.bdlg@bytedance.com References: <20240102131249.76622-1-gang.li@linux.dev> <20240102131249.76622-5-gang.li@linux.dev> <66af5bce84c9b6480feaa2ddaff199cd5722fcde.camel@linux.intel.com> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Gang Li In-Reply-To: <66af5bce84c9b6480feaa2ddaff199cd5722fcde.camel@linux.intel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: 3BF2340010 X-Rspam-User: X-Stat-Signature: fatxn4sdyspbta9eisaeeiyx5ws738nn X-Rspamd-Server: rspam01 X-HE-Tag: 1705046902-796873 X-HE-Meta: U2FsdGVkX199fh2UM4+xFbfmnoVusf5r5T842pR8O9WKL8ylkF6jYey2A7PSpYgFn5Jv56TzV3e+mTKERpmcFqsOCAC76Z/jwEDqvZbhec20e2gPqEtCmPyrgg//n/G1Jw02jAJok6qC65CyJYS280rFXw66sH2OaFwniWz883nROVyJPqT2cE273Kz6ynHnfjtFPyTgUIf/dv4P2HQrRs7SNZFU0dHWtfsNMH3VHZpFu8LW7zxdvQSkHpRINWZ0YXFWRx7uZCRXjI7IqNNTCXtGZWDJLSozG3zEwHW61DnHwgVSOFI4sABQZJRxf2kUZVeT8OO7S7tFzx9a6B85y//OEEow3ZW6zl17dk5TzlXPTNHD2G6LAA6b2Reykjb6kYxJ2Wza+o9Pg7clYvBDhbcs7jKXa7jeTsjEiBjLOXyMX8l8MLalG2Hd4Ch+JfoyaOsHbheJWsyMe2TltFQb3cjO5icWb0lMOKZpl0qfop5eL9mWt9+xcC25zUqgnxw2VpK5UyBCiYt6zQHeSG082BhQQxznRUjnjqAls+jB4NBgigiXdkpRXD+lQY51PXmKvFhsLcMvCqB3gqCSEjzBemW3EsVm6ThdNuEifr34JKgDgTCG4WYAKAU/hOo3PJtSUSQBhG1HLa0KX+xLs7D76XorRud1aCjyemh2q2W276jXvn5GEFtizq14lU4lMxDe7tzXSe+JGhILLEAKEUBQci36Ojp3s6tL2Wdm4rw8UqzhMq5YbFXdxBee8GkAwtEVZ+fHRIo/Zy/XeDB/TGYAG6o6vN054SRgrobIPlVsuzPEmS8jynHkcL+xplivOa2nEUnC2piiUBia6eFARuyq5Vuv91rm4WjqQ+mTn3LfDUY0QVUN1Vzl7jD6Zka9ZjTQRWJjAFSK1rA6KlPjNLDNaGLIot8bh7Res15M8l2KbeEj4DkFYVJ0MB67Y7mj3jS260WmR6iE7r7xYHDhTUv qBzONKQD CmRmxssSK+uQRNoI4uONyJnudipI7OkK7le120NmR/DvSfjoG0NXBo+P7A933RabfmxqvK5T4y3pi2cRXPynAQZp/TDIRWOVZn2AmTEI2kF1f7GT07N6brXoyg2R58J8O8leXAXTujd6GO70= 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 2024/1/12 06:21, Tim Chen wrote: > On Tue, 2024-01-02 at 21:12 +0800, Gang Li wrote: >> The parallelization of hugetlb allocation leads to errors when sharing >> h->next_nid_to_alloc across different threads. To address this, it's > > Suggest you say > With parallelization of hugetlb allocation across different threads, > each thread works on a differnet node to allocate pages from, instead > of all allocating from a common node h->next_nid_to_alloc. To address this, it's > >> necessary to assign a separate next_nid_to_alloc for each thread. LGTM, thanks.