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 BC0FAC4828D for ; Mon, 5 Feb 2024 06:55:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 55EAE6B0074; Mon, 5 Feb 2024 01:55:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 50F446B0075; Mon, 5 Feb 2024 01:55:39 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3D6F06B0078; Mon, 5 Feb 2024 01:55:39 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 26B396B0074 for ; Mon, 5 Feb 2024 01:55:39 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 9A3F34012D for ; Mon, 5 Feb 2024 06:55:38 +0000 (UTC) X-FDA: 81756839556.18.ACDA44B Received: from out-188.mta1.migadu.com (out-188.mta1.migadu.com [95.215.58.188]) by imf25.hostedemail.com (Postfix) with ESMTP id A0007A0010 for ; Mon, 5 Feb 2024 06:55:36 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=ccQs5ggj; spf=pass (imf25.hostedemail.com: domain of gang.li@linux.dev designates 95.215.58.188 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=1707116137; 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=eRwS2TOIVcwCMhMY7CNIPuZ7+8MNYAG3eC4E1bzeetA=; b=yz2zvgiwINx2/fBCyXPWdr50L99F1H2HLB9HbnlYhPbdDKAGs0tD+4r/aLtS/lumani1xf YzT8I/CpS5IOwQD7nIJw8+46RWhAc/wNrlqyIpaaywnxmKU0sk5ovT/oKLQo/97SDF6o+h CyMONBKn+pnOmQiYeJowuNy9R2flUzU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707116137; a=rsa-sha256; cv=none; b=ATyH52qeSvU/38Inn97JTHPRNMh9rLNet27C7Lfr04gmw/U1CDVmclLFh1NvGdG8gYEEEL ejxMFFGhiqQefK48W4ElvWnyvl7jSiObus+g3Qw0UiLVXyBpCBq5a34zkw8bNkmrsVeg69 rnr9qzRhFewO0bXG3z7sj9Qxi+Nwt1U= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=ccQs5ggj; spf=pass (imf25.hostedemail.com: domain of gang.li@linux.dev designates 95.215.58.188 as permitted sender) smtp.mailfrom=gang.li@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Message-ID: <828f990c-11af-42ad-a030-a66dde97a7f2@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1707116134; 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=eRwS2TOIVcwCMhMY7CNIPuZ7+8MNYAG3eC4E1bzeetA=; b=ccQs5ggj9mVzRoAPo/b5x7z+VvMRim4Bkw80breXejHIKe+Dy0DQ8eSyI22OqCsPijTsdL q28E8hFD1w2N2RsulpLzIoL+/Noi7GzteeKY63BwdDlhBvUB749QG1KS11zgCKZ74Tw3Dc UNDueaiectH8yuWEQWKSLTO9abdAJ5w= Date: Mon, 5 Feb 2024 14:55:23 +0800 MIME-Version: 1.0 Subject: Re: [PATCH 1/1] hugetlb: fix CONFIG_PADATA dependency for non-SMP system Content-Language: en-US To: Muchun Song Cc: Gang Li , Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Randy Dunlap , kernel test robot References: <20240204072525.1986626-1-gang.li@linux.dev> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Gang Li In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT X-Stat-Signature: n6uf9xam55ganybyumu1sooaihxrfbo7 X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: A0007A0010 X-Rspam-User: X-HE-Tag: 1707116136-32228 X-HE-Meta: U2FsdGVkX1/JGqFjqkQGHcmuQR56aug+UPwO4Nyq/P7F6npTP267K3yiaDScTIKadvWMQA2ujfRM7O7oSVgEZ9EPt7S+kDbV2f+goT3fWDF+wFk4q7F5gj2YrZe6Kig7avLRh1ykOX5wH8hfqcGdZ8qIBfzma6t1/qhkH4vLH+SeqFhwc/O2+G8YgL0No2WXEeZ7mekTm3jkzkd7EsQjG+JNeZ5Nsu90BG7gvwe4AYPqQ/RalNJa/CIZ/bafsw9TRnrdO8N3CngTJFFxP50/oKP+QrBJZnjIVsUajABdJ4qc33JRJI+ZJA3ymcMwNLOqsHZ+21ktnpbF1FWgAwNfO6UpDdQvRLDYTHRVTBgtnxOAcBu19EY5A9PP5OKhGDRPLhV6jF9y+38EeUOLYWNd2i5I+3l9wJqErAoxLczDvpiRtV6cmAT5grNZkWSZQORB8AY21FfS6PyuTisJ7Z6j4No+L8WizpmpFcoojZ3StV9seVMv11ZVkayj7OrPM5uNxHx/w1V2CSQpw+WqeMdyqbvXTqHyRwe8mpNNSCHv38awju2foDT6tifghbVXEcj5h2i3VE3HKX38LoapU9URvGVEagCD/a5j28UnJuvnau9GI7DLvC60q4Tdb2u7uNe3hOqfj9S4s1B8kjIwN3qJTFrvju2555F3570OAbbGyBQ+ehwDtOTfiDMop+45H+ZlCmA4igNqV4yo0JylxM5X19YBtuG0XhoqxBJlNjjoIXSAG1l7A3qcVtCP4HedP/4RuSNVfS41lbJEI84fiklSN6nxbWmONQPrNCZJEXX1Ob1cT2ueT6Nic41HSuz/sXepmRbQkyQ+hzsaFyapo6ZlsGq7bt/EzaplYtLqEfq/2cztD+JNXeGp7Pk2um1vknTBuahhDvgTx1SvT75IhJZBofftWOxUhNI8kSC469I9Bmko+Her+99wbKHOb2sHlvl8jDNYePBW+AbhsChZDDe 9FbF7pbF xWrHmUYQbhAQkaFPsoxPUvjAf7IBKmN5wIfvii8ashYN3mBu+yM6PArK1JEsgJnysLD+yRC20g1SAGXFU7ZIXoruyuw1fgiRRWuB7RTpsGNSiXMlDK59/b2koTcNO+tFLRwr1 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/2/4 15:48, Gang Li wrote: > On 2024/2/4 15:44, Muchun Song wrote: >> I don't think it is a clear way to fix this. If someone want to >> use PADATA in a non-SMP system, he should be carefully to handle >> the non-SMP case himself. I think the better way is to make PADATA >> handle the non-SMP case, I think it should be easy for it, which >> could just call ->thread_fn() many times instead of creating many >> threads in the non-SMP case. >> >> Thanks. >> > > Sounds good, I'll take a look at padata and send a new patch. 1. delete the dependency on SMP PADATA only depends on workqueue and completion. It works well with !SMP currently but has no performance benefits. What we can do is make PADATA handle the non-SMP case more elegantly. PADATA has two parts: "Running Multithreaded Jobs" and "Running Serialized Jobs". "Running Multithreaded Jobs", which hugetlb parallelization relies on can be easily deparallelize through this patch: ``` @@ -495,7 +495,7 @@ void __init padata_do_multithreaded(struct padata_mt_job *job) nworks = max(job->size / max(job->min_chunk, job->align), 1ul); nworks = min(nworks, job->max_threads); - if (nworks == 1) { + if (nworks == 1 || !IS_ENABLED(CONFIG_SMP)) { /* Single thread, no coordination needed, cut to the chase. */ job->thread_fn(job->start, job->start + job->size, job->fn_arg); return; ``` However, "Running Serialized Jobs" is more challenging due to its various workers queuing each other, making it more complex than "Running Multithreaded Jobs." I am currently in the process of deciphering the code. To eliminate kconfig warnings, other methods could be considered: 2. Split hugetlb parallelization into a separate kconfig. 3. Wrap hugetlb parallelization with SMP or PADATA macros (already ruled out). 4. Split PADATA into PADATA_SERIALIZED and PADATA_MULTITHREADED (too heavy). Anyway, this is only FYI. I will continue exploring how to deparallelize "Running Serialized Jobs."