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 790ACC02198 for ; Fri, 14 Feb 2025 15:52:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0A96C6B0085; Fri, 14 Feb 2025 10:52:48 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 059A96B0088; Fri, 14 Feb 2025 10:52:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E64126B0089; Fri, 14 Feb 2025 10:52:47 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id C73906B0085 for ; Fri, 14 Feb 2025 10:52:47 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 7553A1605DE for ; Fri, 14 Feb 2025 15:52:47 +0000 (UTC) X-FDA: 83118993174.01.90D3633 Received: from mail-ej1-f50.google.com (mail-ej1-f50.google.com [209.85.218.50]) by imf08.hostedemail.com (Postfix) with ESMTP id 8329B16000E for ; Fri, 14 Feb 2025 15:52:45 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=dlkaSNs3; spf=pass (imf08.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.50 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739548365; 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=fPQDSWdyumx+7kZtAbOyAbWC8fKUL0iK50FAOdUwRCA=; b=IEtOb6FdzLA+3maquULqd6xvr6YwSA3PzgFE+i0g9kjjV+76mDX6c31utKe40I91Cx7vnR Ctm8INQ41IfFYMMR0wIFhbYqLpSgdlx9zRdtac4sNHe2q6hwuGS5D5T2sAleIDStMxZEOB zv2K/QhW7GC1beD1uP6EY30oAyORIz4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739548365; a=rsa-sha256; cv=none; b=THSD5IkGnu9TOvxMYdgkMrPdbj2IIxInUqxuGC6MPuXyLxJz10S2RR1dEX9b8NDbQIhqSY 6PHqvMXT0CUu8GXwFpp+piZUFk6kYz4Ba6gcmBW7Cln1FyASadedlayBTRuYwGzSL5fQYn uMhZnv9NssCRefE7sevllpGy2LcyWa4= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=dlkaSNs3; spf=pass (imf08.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.50 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com Received: by mail-ej1-f50.google.com with SMTP id a640c23a62f3a-aaec61d0f65so491919466b.1 for ; Fri, 14 Feb 2025 07:52:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1739548364; x=1740153164; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=fPQDSWdyumx+7kZtAbOyAbWC8fKUL0iK50FAOdUwRCA=; b=dlkaSNs3EN3gcPMG5FUoN7NkFgREtCe994HHHhg1Vl9c10LbArkAQKwC+jDgCZERAE LpNgCeuyqeSgJtu3XHMc8OOtFYlsH01WGydJagbD4wn36EicA9ThU61bLz/oY7/cST/9 rrqxPtizMac9Z6EQNcJRhqo88RGMP2RFWZ3dPT87od8BZfW2EfwurAU34I/FV8LwUHGO glLx8DdhBrxTc61K8/aEidIB9UgTAejvBXxnZBPBi/gA/LRXIAJhSIHjLo0EBHUsado9 UCJXxiqiRY0WM8E+5I0MUmM9MLzpiTSCyKV+5v/mpWS/lNwqZRj/w53ZzLyLPJXks/es yBpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739548364; x=1740153164; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=fPQDSWdyumx+7kZtAbOyAbWC8fKUL0iK50FAOdUwRCA=; b=EQXDMh5ief/6nPZnWTQsrjq/ofghSc4vHaRJBXCQg93VMTd0dR/bGUK2l+3xBMo0nE rh1EqDGJDqicfwQJst14Jx2G5Xc+CoQFC6LDlx3V3pSttE14XXVd61cqoBoAB1XmaMCZ 1l9GvhJv6wlyYuL5r6o+2s9/0msrcbWbu0jqAtO9mCSwCT5kD9idzfm7yQ0W47VMq6Sa 2nqMrmqeZZ/UjM9rwj1Q1sCol1tgVQTLBljRYZSHI1NBWxgSh9yiSqC/v+7J+MTxB9AC xcxuXg0uRqh6IeKNWgMK+U5nZbbHHrp5JYM9mz8gz6DRr29Uwo9cSLcDLpa8TUP8lYvI Uthg== X-Forwarded-Encrypted: i=1; AJvYcCXYpT+O4E4xxA5s7R7GJ71CLdFMVVyM5w47SlfyUSKlqFQG69wk7H/6UmFa3RC9dTXoFwOM3jVnGA==@kvack.org X-Gm-Message-State: AOJu0Yzre6rpbjIH4v3+fMTs497PNRpsXPLV9iz9Ia0serC4YDYdjhVP W7EsfHbZ9HAHI9vl/LZG2K+n08A6M13zc7XdmiWcYUtC6qRQAM7LcricMlldJIiGXc4sghPH7fQ H X-Gm-Gg: ASbGnct2C3shjVhQG3bum4kNU6DAvJY/DgXiHPewSSvH/g9d/IsVAv+6UD8kah2XZdl 1PkcjJ7C3LEMPodzM6wraiy4zFdFhrTKUvjWguZC3Rq3lCVEu4pX/7nej0NRwatvNF8mSzCmHJI LPjUTz8yA7cSckPyNUFk1QrzmZDbuemKQdN1fiiREqpphCBqgKhQek/5zPvv6CrTgXaqS38SX5b czCjqKrqQeQ12EkGY6ld8SJ+dDhKzXeE4dP8/Vv7ke17cDid5ze7auBa5E6vRdsfzsbfUJdBsAD 9oeZLcmfCf7zQBPNKPyX8hckiJ7K X-Google-Smtp-Source: AGHT+IGM4zyda7P3q+Y2IYo5LojVyQ2Ld4whAaXWvkt3be7ScN0HjwuroYqtgMUfJbnJWY08Yx4Lvg== X-Received: by 2002:a17:907:94cc:b0:ab7:da56:af9f with SMTP id a640c23a62f3a-aba501a9dc2mr940172666b.49.1739548363814; Fri, 14 Feb 2025 07:52:43 -0800 (PST) Received: from localhost (109-81-86-120.rct.o2.cz. [109.81.86.120]) by smtp.gmail.com with UTF8SMTPSA id a640c23a62f3a-aba533bee4asm365187166b.170.2025.02.14.07.52.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 14 Feb 2025 07:52:43 -0800 (PST) Date: Fri, 14 Feb 2025 16:52:42 +0100 From: Michal Hocko To: Dennis Zhou Cc: Tejun Heo , 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-Queue-Id: 8329B16000E X-Rspamd-Server: rspam07 X-Stat-Signature: a3xtronhu1k48admmo5q5zndq6nm3bq3 X-HE-Tag: 1739548365-597632 X-HE-Meta: U2FsdGVkX19YA6AJSBSpuEJk5x45ZwbqNjtlRhFEecmSwiV0imJcWs/wG5FVsGUAUGw2vNB+yNsKA5ed+Kd+qd4+9zQ8BBhl21sFzMNoVlEgQVbtN979zmeLLYbZXu36hMZzPo9C+a4ne+NhZ5UqwJVAa/8zNvBW1yT8qUFKc78EnB4SVnRoLKRLn8LQjl6ivibKU5Sye3n+RXChz/BHCuqUzAExZZMMtacmpWlX26CdqXDvU1KaD9t8amCfvsTjviyeVulQeAQVcxN3/imnQ3thaG0pEJ+6pse9JUsOUi1dLbjYZS5LSBeDh21leKBi/p3XgTe944GNpkIEv9cAvIgXv67ZirDYa5l8TYaxhYaKJLO1lg/CLLn35OZhrKKbWNRjviLsvi/noQu9yoiPulYEI+urI34wjJJhGj/zV38ZFLhsi9TTV22AkilvHlHEr8ooA1d/v9GExGYCbEhdlw4RYuCPLNv5ZHcYmhv7WTq1gwkwIw6N22c6oUkOfTSnVqOJCrQR//dr4nESBy4FAu1w9h85M7xX1SNzEIGGrSTzSwFDuWPSC34i2bFIQRiHdZ7Ar4QoSprh2sZLq7b14NMJb15CtL6DHinOcSIcDLRHJgWfRmZ2e5FCKb2UAB3pfSgLTlDCkn2hSm8rLDD+cML4IVfv8jpaKxLbdv7DDoGIT/9p3rWaSvds84ac5UHQCYFaqA91a+iiqasCmYfvZK4gX9YSYVsgpskNUtcvTA3JJwQoMRhhOAtVPgMr/pqO6WFHe/ta9WY1TaPv/FhhgUU1glocHmKtcFr2kFsuC3K7pFnZ74xOJzeOHZMDg7Gr8EuLenETRjJXPhDq0wHl7ViYQJiNkXhK1eDFz0d1/wl6E+1l8OKrLje7rWQxESjZdvFcsypsN8J9aIl2JJAQr24Nel7qCYYlmY+JoAY6mewBmRUN1yxmetOlKfodSrwiK2AEw/njPQtN8mUCyBV 4cNz091w +iMAUf394Kfn3wqFlCOkHwzwPyfV0Cd8zJNTPa7dCtARNkyh5363OXzqAHuzBZInDA9R2qrb8nyOFu9euujV/9bVe+heS7c0+SNQsc2pAqAWxol1exLJORph7SAL1ANDTp2lbRYvRkbyBczRxxsnraqGrHnf2DfEJNBBqRRheQjs3QO9ea/OaKJs9LPsqqtH/rmnSnBrHbcufWkW85zVPZc5Lrr5cB80SHTAeUr7ARWmQDSUuo3cu6jiepNnVSyexLyvTLtB28rQJ7zapMBZrqZLx3WajtbFm6pKrPbzs5NxkpXeHZAVhYlb5IA== 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 Wed 12-02-25 13:39:31, Dennis Zhou wrote: > 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. Correct. > 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. Yes, this is potential side effect. On the other hand NOFS/NOIO requests wouldn't be considered atomic anymore and they wouldn't fail that easily. Maybe that is an odd case not worth the additional worker overhead. As I've said I am not familiar with the pcp internals to know how often the worker is really required -- Michal Hocko SUSE Labs