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 EDA47C02198 for ; Wed, 12 Feb 2025 21:30:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 881A86B0085; Wed, 12 Feb 2025 16:30:12 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 832336B0088; Wed, 12 Feb 2025 16:30:12 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 720D56B0089; Wed, 12 Feb 2025 16:30:12 -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 53A0C6B0085 for ; Wed, 12 Feb 2025 16:30:12 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 075EAA0E64 for ; Wed, 12 Feb 2025 21:30:12 +0000 (UTC) X-FDA: 83112585864.16.7E03A2F Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf15.hostedemail.com (Postfix) with ESMTP id 5353CA0002 for ; Wed, 12 Feb 2025 21:30:10 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=jmxOk7fE; spf=pass (imf15.hostedemail.com: domain of tj@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=tj@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=1739395810; 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=sy3KGoo9YdFBSqr3eacg7CuyrRJxIW3uTEIXstIl6ec=; b=AK+Ery2vxwesSraLyIddGUIwmMFFb00nkagc6VmkMZB+2dyGXpRsaItviiyW3sEj8TUNRN FplUeU5w9p/2dIPd0IL962omtlo12Nlx0GTzUEAWcrgmm87ioWjXMdwO7SiOqza6U1zR0U vQQGKP/Jf5DWxzEXxCvrCBOFDSmPhuM= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=jmxOk7fE; spf=pass (imf15.hostedemail.com: domain of tj@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=tj@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739395810; a=rsa-sha256; cv=none; b=vI6LIJlL9BNROkVDAoglR+tr6Jxp8LzsPVWTZSydssCTBq8wiVFlToJyKMwPPrZFbFOad1 8Edidls4M1BVCM3coi66WrujiI56GufuGCRR+CPxARfF4A6qXyhSJAyQ8AmzSxwulwTw0S 05zo+kOixIuHQOpHnY8zfJnsJexyZZA= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 04CC95C5CC9; Wed, 12 Feb 2025 21:29:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1B781C4CEDF; Wed, 12 Feb 2025 21:30:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1739395809; bh=E11JdGdSryE4u0Zj75nD+BOOC9K1hxW6LuRwZCgPYLI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=jmxOk7fEH6KfaykFBtirOyC0oMQup5NfTBne2E4szWsvNk7vMzgmFtSyvqsWpVvy7 Y5HOr7EU7Zm2Amp7eprapQ8NXhL2coJ3jvPCt/tOdDcsNjexyhgo6B+085ZqoXcmV9 eqaGE//C49gj1NWkwHw5gUbyGWKgrxKbymxkl3+84xdfRttir1OrzlQRZVnPBXW5aG 1kCyzw1uz1TtTeh3jQ6dfYY4mE8OHztmIUx8WFthQ3bFQEF7Dcry4PwcI5nGEht1tr BJEQeovg3POnPoVJEIVrWbaxEYtxiJ9XP5s2i18ltnTs6xcZk0j5PCeUZEfHWhzpQO Djm3OETH4cqGQ== Date: Wed, 12 Feb 2025 11:30:08 -1000 From: Tejun Heo To: Michal Hocko Cc: Dennis Zhou , 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-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 5353CA0002 X-Stat-Signature: wgpjz1aci4ebn91aw7uyzkyusgmtwmt7 X-Rspam-User: X-HE-Tag: 1739395810-439346 X-HE-Meta: U2FsdGVkX19qGdYRcUbakQeLiU8wMjuSaqGkYzGXqMlHwKiEhY8QfBF9n+cy91HVAp72+CcC6lIn8H5jd+73kwVxIikgwZrq0h1jO1JcZesIXp+98o0wMTZsPyaNp2c5fcYqlOxnwYjTr0ku6cmjL50vUMnVU+1oo9398qK5xZ/x5akM6vziMkST/9GjHItoXGVmwdHtEOcBs0YFmd8V98oGhmgJ4gXqwmoLyw4Cm/vRsl4ofxOwhwD8n/kuhEhcRdpdyZTjZG3oobGH6yQukKLgxFQndDoB8XON9efc5mX266iUIof7QDfM86uR1AVDHRXpGmo1pkmuZKdQ7udBv0h7+O+1XLB+Kn8ITepgVcf7Tx2mMQzPqYI030Y0rzRkpH44Hq17ye/TjNfAmoEPAw390fcd6zlcD+OkJ11tbBHhs2jICkSupYt5ai7ny2qFZv0YpoxI+uNBRrdJgSHlH1zDR4QaafADGO38A7+UJK13K95mKF5CqClkvaSzYORP0IZNBmxkvLHF4JEJE7lGHlIwsQGoDXB5G/m63jgrB+7dw9zFCoQO4yVm77shT4rAGJWa3Kk3xWpKYu33KJQTzpg3xiq9T8qOLWdbXP32ajcb//BhmmYJnZRavzHP9Nfqh5kG11a71CAt8g3Mp5QW8TYjpwfZf33k15aWO65uqY/KrPNOYNgwjn2F78AOtie8Prqytzhl0JsNB7f/WeKN3yDa8x57uPYucsOWw8KVFk7anZPnIpGDtFbQkgK1cAh3T9RoPbmbufUYkQ0FIHDsYeUnq60o73XrIgmwYg3+87wSfG/eWQ4Tb6RdQud/othUAf0kPVQaNAnLRVIlh+4mVBvIzttxsN9KOWj91GiGMRjsv7zP46j/aQKxvj4ouGYGW+V7vijEok7V9EKBl54b6YJwODKSAAGOkg8N/ljLHBcD7WwBm1bAz2HRR+75DL7sRi4ANPli6luqR4j37dp ZVlqG2/o Cv+bv5oDSWzvFcO0YmPK2MtCyS8Zxi+W5BfhLSS+947zi6o12FpbSuVqR0UPV/jW22UjPaZ/n5TBCj8RavrO83nBNgiPSgyRp2aS/4CeNiusFd+bqQ7q+gEMYQxk3HDzcHCEbPao3bQiLWKg8i3c0ebAXQEcHXfs55udkrm682E9j0YQIjluQweRVPRbqkl/OuDVGgtI+J4MeowzavlGOnPKIzg== 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 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. > 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