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 A3310C02198 for ; Wed, 12 Feb 2025 20:53:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 206A96B0082; Wed, 12 Feb 2025 15:53:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1B74B6B0083; Wed, 12 Feb 2025 15:53:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 07E796B0085; Wed, 12 Feb 2025 15:53:26 -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 DF4E16B0082 for ; Wed, 12 Feb 2025 15:53:25 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 57404C0C0D for ; Wed, 12 Feb 2025 20:53:25 +0000 (UTC) X-FDA: 83112493170.12.225DF56 Received: from mail-ej1-f50.google.com (mail-ej1-f50.google.com [209.85.218.50]) by imf01.hostedemail.com (Postfix) with ESMTP id 1D80C4000F for ; Wed, 12 Feb 2025 20:53:22 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=SKODnKkt; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf01.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.50 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739393603; a=rsa-sha256; cv=none; b=6eRqapGPz8Q6Y21M3NxuAf2U4NhgkvTOf4JF62Db97UiWZHlqvZ721OZUZkE4bmUYRl6+w NhcLR26wrc0pMKCqM1GE3MryuqHWiH7vSCqMcJLCE3qLQBeR08T13xlGdDwnJUWUHSqS4L CgAy8k8ANtKike91CMhFfrqlubDRfwI= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=SKODnKkt; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf01.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.50 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739393603; 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=BI8Hs29AlJApHYUeKxAiymuqiMcyKQBfc27ErxehKn8=; b=0FJTaDOBPAh8LPTR/x3vRwlvIdVyoP4E1zar1TQ49xImCJb07a+962MQOjqTZ2pqBwQdtj ADrmi3Igb2wkwCdyqHsWoJmWFaNiSrPhnZMvh7e/N6Fdm38QEyhBmJ1z0DdbDdZzz9JM/s Dti8XfTlG96h6lrG11pgdkONLfLsSWk= Received: by mail-ej1-f50.google.com with SMTP id a640c23a62f3a-ab7f42ee3ecso43284466b.0 for ; Wed, 12 Feb 2025 12:53:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1739393601; x=1739998401; 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=BI8Hs29AlJApHYUeKxAiymuqiMcyKQBfc27ErxehKn8=; b=SKODnKktPBoQZRo1RzHuRqsgmmh1FodPotZ8yJmYm6IjdrCAIAhkm5UopKjPDcSID+ 3Yu//Kh2htPSkSMeVZIwZabax6mDx0PG5Bo4+UAH1IWXMiXOkPJjxtax9+Z6Eg9E3doD 5iP3+gP7Ob8LWhXk4v8/EC/hNZu4BxF0K33tEFQhKjtL2nomjX6zqtCqylCF8LIZ9iJX nB1E7Wsf/cZ6O69X/zPDjDVAv8X3c0bontD14r3bJe1u45qHR3ld1KyhrxfftgZsjJ/1 oSYnbcswcsbw6JzDtWXw4s1mqxK13h2PwwPX1HHyuKEGnvtka9T4w/CvWnADJ8V1ARMz AYNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739393601; x=1739998401; 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=BI8Hs29AlJApHYUeKxAiymuqiMcyKQBfc27ErxehKn8=; b=dsJ7XHYx3yLD3vD+U1D4tfjvtgvasMWsoRX0FlTKis1TAzcE3Fw1R7ranMe4n7HToN YT3GZZg3PUCM731TxSr0B1BUzSuyrf33Cs43lMPJOhh/HjUbq1XqJnSus7S1KCGYOrRA X3mMlKiadmGZWWgL/3GkIVWpUjkEsEQXtH3PKJC1PdggyqDbXRS19Z1XHMJR9MeS8iII 3jxis/FypTdj6DsOyoGXPaKZpUlBPu4nmo3jH+DBtjgSJ8/jmgtA3kO/bXAwGas6EaSQ Rr7xo7SyWe4vK/teN/eYMfJ8RU5XqC+fR0PfZXxhjnc/lxcChdMQq7tXtJjs5Xa4Dxui k3hg== X-Forwarded-Encrypted: i=1; AJvYcCXc1VIv6PVachJjoAy/M1cHpPOcL/m3hMdxS09J8XCVUowiqrgBrYzOX/bgEZzFFKEei/BmlyOPeA==@kvack.org X-Gm-Message-State: AOJu0YxoMdjsBhRd98WqHI82rWO63g9u3LBYTNXhJcG4Jx8JSvrlz32p hACAQnGmiOpXtZRFfatUEKekXiZlbBSf6PbFZU8IpDOw+s7OS/+zGZYG91+UyUg= X-Gm-Gg: ASbGncvPvBcdTSEZC6g8Oa2/MaGL3gDBfJ3ly8CxRA/vG6od/Ny88oDZXSgHHCgmNin fPdEn77MQgO2LCVeXoxhyIPPMsUuQRB25IlV8vQwygb0a46sl3DBs1WpYkdOwKuwOHZAUtxYcm2 ytBJbNqzuxYBFpsL0EPQarjwCdIRXDeZTf4gLDxtcmLvl4QXY5TwmQ8x3JgaiOHVOHeVn+k2mtS Hzo7NfMLseve54U6jANBstCgR/ImZOUoWOsnwzm79SD9eMwekatF4dN/6/VTMPLgoy0u3ixHcM5 W8aGGjAhZUvh2RN55+vC9kqVp5Em X-Google-Smtp-Source: AGHT+IEKdM0BPU6QxdXKNjigkoD51P8a49+kUcF9KZW04xn8FPIS+yrnI8fi3qoqlEXMlCEeuaY6oQ== X-Received: by 2002:a17:907:971e:b0:aa6:5eae:7ece with SMTP id a640c23a62f3a-aba5018d567mr53227966b.43.1739393601385; Wed, 12 Feb 2025 12:53:21 -0800 (PST) Received: from localhost (109-81-84-135.rct.o2.cz. [109.81.84.135]) by smtp.gmail.com with UTF8SMTPSA id a640c23a62f3a-ab7d855b61fsm452250766b.124.2025.02.12.12.53.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Feb 2025 12:53:21 -0800 (PST) Date: Wed, 12 Feb 2025 21:53:20 +0100 From: Michal Hocko To: Tejun Heo 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-Rspam-User: X-Rspamd-Queue-Id: 1D80C4000F X-Rspamd-Server: rspam12 X-Stat-Signature: ck3dqso3jhppiiwu3ihfzgaox8fspz9f X-HE-Tag: 1739393602-229688 X-HE-Meta: U2FsdGVkX18wskg/sgWbArssyJ+Natu0rgvoehaE8lZ1hom01IWuMQ/wOvupXEDJk4r7IkTOaypCf5GdsAb52MI6mmdCBAn8Gr6/nLS2jFvUWaLAVsmByX1yyRdIzMkVuEvU/ThOxDEmxXJxVbj6dSxbFrURh9VwwZzH+R3npveJIToV89RiKvi+x7Gh1ARYVKYOtdPttK5uR3+10lO2CjQeQEhltyBthIlVojytIefZpwXLytUBVeCN6oL8Xz6eFouxPiH4BhtY5+R0bGxtOFXfyhPTpygRFppVYZwuxspXbdAF62zHbVYn+ThUa96+CRxkvWMPYUenj4jTdpnrnuglZApXblMMll+vl404XI8iig/StHYk5ojUd5UpG6HR3apRWtjZdVz4iSH6N1jUPPs3Sfew535/7lUnnI6AtMaQfC8V/LxxDTg5/xVa6qbsECSJE85nt2hE9J3UVwx09nNPb6vdo8FSF4rBA2jMQY9G+HtwisF9sJJKHVF18Pm24ObiwWdGRju5nlAswKZmoxaT37sHemY9QJA/SR4XPjuId1Yja3fXDCF5Ju2ph5Ql0uP23czFHHP5a411VUtIbR56ODdg3HDh5d7wWgYBrGX+gDG7SbgUI9vZvBs5huHqEYVdX1jNBrVCxiXSb3sh2+GMU8tBeNk9xalHkYvLobdlDyPmJ5E6fmSSgcaeJhcH9IT8nfHnDBktmYFSRvOFdvVX+IzGn6MxO3ZjJiEJsiZDkZXGzZHp3SkDmxQKciI6D5FcXy2Its5JaUt2hTEoth/bUPpBtW6OCiZkNgv4Oc3P1cnEjgUwVT6cgwDHG6JMIkSHRrGWBh3o8rS3PsHtK93ffhuux0BtZjGB5Kkd0ZydqdzLFQzkHFqgJZDY8GFP+MAuEd2sEIgPsot2A6W86PqeVGQ2TfUJ5TeACbgU0iCTHqJLlHBk2Srbk9QXe4V1PCZj3KAnMvA2KTvvVdQ gmWAs4r+ euAMc8JcZSQG0Y4NuGirfPJklZOq1AAO7WJfNCAB8WIfcZ0KhtnpiWItrZt9Z2h3bWOppO7fPl7y4WEzkAKWmUlgCzv0vQQddPbQYnJIRLypQRFcu4LdEtue6oHkBle/pDKJo/OixzXf6SCcTeohrxT2hOjonOeuCAzmIU+DWC1wjG1KQxG8+HrSxgXm1g9KQ2/jhuFDB6KanwaG3jJHg2hycCcGzJg90v1oRFCwcXL+OBN3Fzo6YT5rFA5pcrrVhMmXfnffOpEO9p4ixWlpiNSlMW4JVmEDep/Pi3NPl5qt+WqTz8WGNH0dBCw== 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 08:14:35, Tejun Heo wrote: > Hello, > > On Wed, Feb 12, 2025 at 05:57:04PM +0100, Michal Hocko wrote: > ... > > I have gone with masking because that seemed easier to review and more > > robust solution. vmalloc does support NOFS/NOIO contexts these days (it > > will just uses scoped masking in those cases). Propagating the gfp > > I see. Nice. > > > throughout the worker code path is likely possible, but I haven't really > > explored that in detail to be sure. Would that be preferable even if the > > fix would be more involved? > > Longer term, yeah, I think so. I can invest more time into that direction if this is really preferred way. Not my call but I would argue that the scope interface is actually a good fit in the current implementation because it clearly defines the scope of all allocation context at a single place. Ideally with a good explanation on why is that (I guess I owe in that regards). > > > Also, doesn't the above always prevent percpu allocations from doing fs/io > > > reclaims? > > > > Yes it does. Probably worth mentioning in the changelog. These > > allocations should be rare so having a constrained reclaim didn't really > > seem problematic to me. There should be kswapd running in the background > > with the full reclaim power. > > 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. 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. -- Michal Hocko SUSE Labs