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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 86E78C25B7D for ; Wed, 22 May 2024 22:46:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Mime-Version:References:In-Reply-To: Message-Id:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Ejb7sOhtTK/pww7W5QKK6w9xXijPfLGrb+f4Qc6qmHc=; b=Ggpxs6taFdHzQS xC5N7DfOwcoHZ50gXkBUGWV0AK3miDl4bM95zTyW0LQHhB2LG+Cv622cP4by5AIheaS+l5l1ChOZP klJ9FmmXx+9w3mLyXs+dYeQBPdVRbB/acI29z9M+sp6PUvql9qcR/Jf3GhMTzLNPup0XTCN612Cy9 N21MxNc3V+dnDbqdNAgrpEqz8bl/t+d8nHr5VK/cSN/GTAFTBfT7GGg1j61E7m/QDE3CsUsAc/Q3E GmHpfeuUz6jTJg0qMA7deS9deJBMVpmaHG6bI4SjaWZIlqIkD31rPXM6F9atM7XkSKvuByYCtqYOx TAdJFjKoYvSurDSOsaaw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1s9uis-00000004JuB-2hIo; Wed, 22 May 2024 22:46:14 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1s9uio-00000004Jt0-1kcc for linux-arm-kernel@lists.infradead.org; Wed, 22 May 2024 22:46:13 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 8EB1B62B44; Wed, 22 May 2024 22:46:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A11A8C2BBFC; Wed, 22 May 2024 22:46:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1716417969; bh=Wt/lYOMjZ5EiLqgZDOMSYLAv6ghVbecXbWEEUnbdvAk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Difkpi8pE8zKRNDX2+VZ7EyZcNiHjM0HR8FJLGZH0pip8MxP1u7thd/rd83PcA09V TVYuNLsB9uDO/0L6O8a4XCtYe8AGfV2GMFw/WHUCsVYFKPfQALg/JlSvIlzFXcExDp AtnoA3XHUlrJl32QhYOsFNsXhIwLTMDFKtCKGeoA= Date: Wed, 22 May 2024 15:46:07 -0700 From: Andrew Morton To: Eric Chanudet Cc: Dave Hansen , Andy Lutomirski , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Mike Rapoport , Baoquan He , Michael Ellerman , Nick Piggin , x86@kernel.org, linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org, linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH v2] mm/mm_init: use node's number of cpus in deferred_page_init_max_threads Message-Id: <20240522154607.bd5790c0b0dc642aefd3a05c@linux-foundation.org> In-Reply-To: <20240522203758.626932-4-echanude@redhat.com> References: <20240522203758.626932-4-echanude@redhat.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240522_154610_568360_43F7BF74 X-CRM114-Status: GOOD ( 17.12 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, 22 May 2024 16:38:01 -0400 Eric Chanudet wrote: > x86_64 is already using the node's cpu as maximum threads. Make that the > default for all archs setting DEFERRED_STRUCT_PAGE_INIT. > > This returns to the behavior prior making the function arch-specific > with commit ecd096506922 ("mm: make deferred init's max threads > arch-specific"). > It isn't clear to me what is the runtime effect of this change upon our users. Can you please prepare a sentence which spells this out? > > --- > Setting DEFERRED_STRUCT_PAGE_INIT and testing on a few arm64 platforms > shows faster deferred_init_memmap completions: > > | | x13s | SA8775p-ride | Ampere R137-P31 | Ampere HR330 | > | | Metal, 32GB | VM, 36GB | VM, 58GB | Metal, 128GB | > | | 8cpus | 8cpus | 8cpus | 32cpus | > |---------|-------------|--------------|-----------------|--------------| > | threads | ms (%) | ms (%) | ms (%) | ms (%) | > |---------|-------------|--------------|-----------------|--------------| > | 1 | 108 (0%) | 72 (0%) | 224 (0%) | 324 (0%) | > | cpus | 24 (-77%) | 36 (-50%) | 40 (-82%) | 56 (-82%) | The above is useful info, I'll hoist it into the main changelog. > --- a/mm/mm_init.c > +++ b/mm/mm_init.c > @@ -2126,7 +2126,7 @@ deferred_init_memmap_chunk(unsigned long start_pfn, unsigned long end_pfn, > __weak int __init > deferred_page_init_max_threads(const struct cpumask *node_cpumask) > { > - return 1; > + return max_t(int, cpumask_weight(node_cpumask), 1); > } It's an unrelated cleanup , but that could be max(cpumask_weight(node_cpumask), 1U); and the function could/should return unsigned. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel