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 7FE2EC02198 for ; Wed, 12 Feb 2025 21:39:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0495D6B0082; Wed, 12 Feb 2025 16:39:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id F3CB26B0083; Wed, 12 Feb 2025 16:39:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E042B6B0085; Wed, 12 Feb 2025 16:39:36 -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 C18726B0082 for ; Wed, 12 Feb 2025 16:39:36 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 7250D160E51 for ; Wed, 12 Feb 2025 21:39:36 +0000 (UTC) X-FDA: 83112609552.05.EE19896 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf03.hostedemail.com (Postfix) with ESMTP id CC2292000B for ; Wed, 12 Feb 2025 21:39:34 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=B6ImokNv; spf=pass (imf03.hostedemail.com: domain of dennis@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=dennis@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739396374; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=QD6ukgV/iZ5CQ5xfOfgxFxz373IS85rG0n1z2eWzil0=; b=3DEvwUS3XOnTIHKc8hvSAO6g7vYEb//lVeOoAtp33gfbv7jccHvdQSxb5nlOLFk0XlCf2U jF1CzCuvUNNyHBHdCtICMOFw4EUvzBRpaLDHjZ6y7bIqAltXXDnwnDFyFiFrqLZrSQSC+0 2jXfDE6GDJkkOdLWtsmifDYdu0mvUCg= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=B6ImokNv; spf=pass (imf03.hostedemail.com: domain of dennis@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=dennis@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739396374; a=rsa-sha256; cv=none; b=M+fpcSVhkvWXorSrHTk0PQfFWp/L0TIxQ10yvIkgPhcWXO1DJCvFH8iT7/oTNPLTSDbRUG 0s9gxSdcf03yIdsdKbz4F+5SP19UWKEGA89HyKhl4+MkRgjZwwl0SThFRbe409Mg6lovBH EjcDqaHLTyZTxQ1x5DfudIsHs4H1zSk= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id A27A3A41B36; Wed, 12 Feb 2025 21:37:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7DDC1C4CEDF; Wed, 12 Feb 2025 21:39:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1739396373; bh=pr2yrsafDhKUbtC2sixLFWxb8O5IOm3xFSNn9pYZMqU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=B6ImokNvTjA9xoS+RjGXSZKju3LmNxYpdf3UN6RbR5m5CsDG6wpql0Rp57Ngs0atP Zw+0wGtL0G6S+YTTn4n1m/fvAs3cQLmG1KiH4VwDdCxNmiOo8TROoSWieVssw0gqun 9CgRCAuOLulr+PKOaPI616kMTQHxMQA68QIZho6q45jAckZhc6A7H2k0RFXcRSzi30 e4dWdqgn9P8H6JG1Kly9gP+O9q6YmToRAg8avqcbBwSIc0SUirDoDCe1vn2827aNOq osZZFPEwW8ii0ZsPWcDcMyzNPy9xdHPfxlSOaxHRspM0kVE4RugY3NulixUo+5vSgT vnxr4X2Nl/JFg== Date: Wed, 12 Feb 2025 13:39:31 -0800 From: Dennis Zhou To: Tejun Heo Cc: Michal Hocko , Filipe Manana , Andrew Morton , linux-mm@kvack.org, LKML Subject: Re: [PATCH] mm, percpu: do not consider sleepable allocations atomic Message-ID: References: <20250206122633.167896-1-mhocko@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: CC2292000B X-Stat-Signature: iruq5eob41o3a1dxfnesinsarurf51nb X-HE-Tag: 1739396374-784094 X-HE-Meta: U2FsdGVkX1/djl8KVwVvoK6NBR2tKvjflT9pSlg+PlzNasAQ3SEBOAuEwX7NHU9W/MdxN+YvXXTOm4ZCdyXvjMN81QO9U76Eg2WZs4atmMr8IaVENtyFY6oj5YSkIL23ZTY3hoInKWw3CLguURzoB/SeIQrEuLDzX3+Q6pEAdLgbc7N05tchpd9GyY1SY6AOz1uxC+UPRhOV33rKlbhwtZEnaLDBVKUBhX0xhF3BexFv5OQXDdMnUOo5jAS86Fbix77DdQ0vvi+/wvA+Qyot/pyMSyHYYotsBiccJaSTniszkXdfsYGnOp86zK6KZOluKn/oyfA29867AboFqBTyctV4afVsFwrqVR0o/5Lbw57MG+TimX+HMDA+QF3ZEID1/ZkxhY2A25qk8Dq0aEHQqDWNiUPFqpSmNXy0kz7YPsjA74fO8YOJpJPRkVQacQkQhuSITKGBfKCNl/OJ0Gek3F6SsoePQ6ofyWe8K0RcVvab8Cp58k6wD1L/F+75/wOkWhfQELaKNhikAMz5f2+YqynsWRRjY3EEyJYP+XxtKwF/JCqVKh5E7d1ZkbesYOE3jHTNEZlDQrS0G9nZY1Nmvl9Jx03ZwAhDkTmQzDwAU4PN9BqQ5POKTdCGUqxDf6i7idF1GWcK8KQbo7wSRE112xxbmgL6zGNYWqLzQPKyIRUuB6Ak0V56Osi1qrKgjfx+74Vkzznb0NynQfnhBFEkf/4X3rpHNtPfUVA/3zNCcY3Xb4I56Ef9Qywhk4z+r30rHnR3plVPVFMjAg9Dg5yRE4pnr8yHH+RsLfkhtGZ+BiERwP33eOPLQDC0TvzvtJcJkwbqnQ7QEhZYIp1mXbHL+x97Uhhya6q1M0fput0yPrM6sx2KmxkIyrqwCQKe2ELaawrhZDQQXv2E5uNowF7TnpRlH6mMVkPcVYtl+avGFWDPj+I5hXJ7pPZmxlPH6CS4ij4I4XT6OrukC5UGA48 MhlnH4OG vzs3Sxbf7N1a4/XcBY8Ff/h9CQeeWz60AsQXrEBiJvcNoM3a5r8sGS5Xjqps5Nwuy0NmOx+YuTxmZ68Fv6T76FfDUElkibe8mtXjYrSpXN5ax7PSgP5Zdx/mIEk+/OtFflrjmaUrKTitQKvcIcKnuWaBN6U8tQax0AOvj/bnIrRHNAqJ9jVCFDSHmesQ4N2MyoKZh8dQca6HZrrMMZk17yNJi/BXo2a4Wowemn7jsx9oNmOxpruiVtINu4w== 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: Hello, On Wed, Feb 12, 2025 at 11:30:08AM -1000, Tejun Heo wrote: > Hello, > > On Wed, Feb 12, 2025 at 09:53:20PM +0100, Michal Hocko wrote: > ... > > > Hmm... you'd a better judge on whether that'd be okay or not but it does > > > bother me that we might be increasing the chance of allocation failures for > > > GFP_KERNEL users at least under memory pressure. > > > > Nope, this will not change the allocation failure mode. Reclaim > > constrains do not change the failure mode they just change how much the > > allocation might struggle to reclaim to succeed. > > > > My undocumented assumption (another dept on my end) is that pcp > > allocations are no hot paths. So the worst case is that GFP_KERNEL > > pcp_allocation could have been satisfied _easier_ (i.e. faster) because > > it could have reclaimed fs/io caches and now it needs to rely on kswapd > > to do that on memory tight situations. On the other hand we have a > > situation when NOIO/FS allocations fail prematurely so there is > > certainly some pros and cons. > > I'm having a hard time following. Are you saying that it won't increase the > likelihood of allocation failures even under memory pressure but that it > might just make allocations take longer to succeed? > > NOFS/IO prevents allocation attempt from entering fs/io reclaim paths, > right? It would still trigger kswapd for reclaim but can the allocation > attempt wait for that to finish? If so, wouldn't that constitute a > dependency cycle all the same? > > All in all, percpu allocations taking longer under memory pressure is fine. > Becoming more prone to allocation failures, especially for GFP_KERNEL > callers, probably isn't great. > Wait, I think I'm interpreting this change differently. This is preventing the worker from allocating backing pages via GFP_KERNEL. It isn't preventing an allocation via alloc_percpu() from being GFP_KERNEL and providing those flags down to the backing page code. alloc_percpu() for GFP_KERNEL allocations will populate the pages before returning. I'm reading this as potentially making atomic percpu allocations fail as we might be low on backing pages. This change makes the worker now need to wait for kswapd to give it pages. Consequently, if there are a lot of allocations coming in when it's low, we might burn a bit of cpu from the worker now. We could take the time to split out pcpu_alloc_mutex and pcpu_lock more to provide finer grain / concurrrent allocations. But I don't currently have a justification for it. > > As I've said I am no pcp allocator expert so I cannot really make proper > > judgment calls. I can improve the changelog or move from scope to > > specific gfp flags but I do not feel like I am positioned to make deeper > > changes to the subsystem. > > I don't think deciding whether always using NOIO/FS is a good idea requires > knowing the percpu allocator that well. It's just depending on the > underlying page allocator for that part. > > Thanks. > > -- > tejun Thanks, Dennis