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 2D7FCC02198 for ; Fri, 14 Feb 2025 15:43:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9F1D66B0085; Fri, 14 Feb 2025 10:43:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9A2346B0088; Fri, 14 Feb 2025 10:43:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 842AA6B0089; Fri, 14 Feb 2025 10:43:36 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 63EC56B0085 for ; Fri, 14 Feb 2025 10:43:36 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 37ACA1A05E3 for ; Fri, 14 Feb 2025 15:43:20 +0000 (UTC) X-FDA: 83118969360.29.D352019 Received: from mail-ej1-f52.google.com (mail-ej1-f52.google.com [209.85.218.52]) by imf30.hostedemail.com (Postfix) with ESMTP id 2890C80011 for ; Fri, 14 Feb 2025 15:43:17 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=YmS93erE; spf=pass (imf30.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.52 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=1739547798; 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=yfchgde7Yv7qF0UntuAhBqD+duvdBiOGtsjacDnwNCs=; b=u9bdUjwFUAyF2ab8qRne38oqn3u/u+jwX5O/U+mPxPnZCU/tUrdNTRJciAlKKqjhQc8qxd /hMmI2iuEI9BkDyWlBIFoLL6WewJZrw6GpTjb+ptrETEBAeGEKd6dJDUGRL6uagOLFImjv xzmw8SL6PZthHtY4j52T5UmdZdYQuLA= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=YmS93erE; spf=pass (imf30.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.52 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739547798; a=rsa-sha256; cv=none; b=OG36kIECBs0xaApog2neZT65IGw13G8/3Tkm1OSU2xcXwtzhOScEsNKvVPb6+mvcl8HhCV 2MgFk2roYm4Ej7UrSGSaRNeu+3RFKrXmXLeAJkw1MbH8/5sCH48RmNcLbAMeKfHnTes6tM pfgq3Ww/6NCCYdKPMBLMDyXLIU5v234= Received: by mail-ej1-f52.google.com with SMTP id a640c23a62f3a-ab7ee6f54faso259754566b.2 for ; Fri, 14 Feb 2025 07:43:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1739547796; x=1740152596; 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=yfchgde7Yv7qF0UntuAhBqD+duvdBiOGtsjacDnwNCs=; b=YmS93erEi2MZLjYA/+bYGHlBxxtFBndTDHOWRylJg+wORZ0zHonlepiOi+uypb5T0r fe33tQF2yMMvcd7/Msb7AcnT9s0ndWlPIcObbGU37cUpRiWWDduFdoUP+Y4ytQMtEpO9 5/sSnvIjNiApYGTb4vBWSSLzA8xaja9f3e05IMQFzLKbYWMiyN1lLtl4+DD1A8qF9HDI sIPhhPtgNz6DbRQx8kr6rKFs6zulszOiV3Lxc0/y+sj5eAnEZK3W8MFepqVD2A0SHo4T DyxlaHKA1bB/JVNn+Aw1CnLulo65m5e+N/JHWJXm7+jLGKOPm5DBEyU6vLVb1DTEhT5D yfew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739547796; x=1740152596; 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=yfchgde7Yv7qF0UntuAhBqD+duvdBiOGtsjacDnwNCs=; b=QJucEyXCXWSZsqqKWacrKlN+1CJlH7Yaow9of5QEKfVQ4yqZN2Ei/VCY9TXcp1M1uT YTiuC/bjRAXtVGBN40gPoHQdpbzG8RSSzAO6fTWDoY5WoIoLtW9gQ5F/3vvf3l8fxFDS PzpdSE4pSVWsf354NXG1ydirhdzXnKAk+OUDg6wso1P4S9p5c4+MoKRpdWTmydkoe7pm gzTsJc1c4hVIOGtg39rMQJqvrgtYdVephRiMrUMENDEwKCtIqcGM33Pi7q7FsuN64EMt JJkSAM2vYl0f7frGVHgABaG3qwc88aK0jmvoG51UpLtb/SbBpL+//VJXi19hk7V6BAm5 CV3w== X-Forwarded-Encrypted: i=1; AJvYcCUPVeMcaswwdTsbyAw4295Yg+ztu0lbaPWV5UXUTyyTQ0SF6ildxutWnK85cdIW2dONJEHdMCXbuA==@kvack.org X-Gm-Message-State: AOJu0YwQq9vWhO9ZQC+2UbohwC+hqFeWoMFW4eozYukoyx6RUMCZcLJu 9xs8q15W71pOrZmTx2hTrb+mpGRjg0SPjDysBnkJT24dNCpW0d5Uga8aBfqmuG4= X-Gm-Gg: ASbGncsVebxUNVByE5e3PFp+CFyk1zHIFkwI+1/SIma5vKt70cQGDNXLFxP2Z9pSk3S b9YogGyRkZ98wW2ItyrYYAQ1u6w4n2yOcDwgVOL1ZgxUspUFTyqWXBEDL29aga8EN2sNmTP+biK 29W5eV8sbynCGsgBZVst7H/XbqCkW2X5/1NHhSTgaYm8Hquw0TLUu4BHkhwNMbL1xEZN/7YgQQe 7NheI3hOSC5qIw/Ohv3KNwCRpfQPJEOd+myBHb6yPZ80tZI8ed7QLz2GrHBjFHa49tS0nPfWSEH IeIRzFVQT76AcGyyfDOJdtndxfmZ X-Google-Smtp-Source: AGHT+IEljRPkHUwrGSBWwsbIq5yiqXebPZljtjhoLwsqrpKYJJh82UYEhWEqnhbpnAgox5pTITjMog== X-Received: by 2002:a05:6402:278e:b0:5de:b438:1fdb with SMTP id 4fb4d7f45d1cf-5dec9faaeb3mr18928193a12.30.1739547796513; Fri, 14 Feb 2025 07:43:16 -0800 (PST) Received: from localhost (109-81-86-120.rct.o2.cz. [109.81.86.120]) by smtp.gmail.com with UTF8SMTPSA id 4fb4d7f45d1cf-5dece1d360esm3170687a12.43.2025.02.14.07.43.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 14 Feb 2025 07:43:16 -0800 (PST) Date: Fri, 14 Feb 2025 16:43:15 +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: 2890C80011 X-Stat-Signature: um67yomf5qtr59m5jer5yddc33d5nosr X-Rspamd-Server: rspam03 X-HE-Tag: 1739547797-724287 X-HE-Meta: U2FsdGVkX191K6upeEEcr63a0b1FJI9PreAJWN0Q8I75DAt4My4gQi6iR2Z5qvh1+bfE9aDfpb0WQWYelNBVzLC/vlDmTFe8hF2M53805MChVzR9TIsEbvkFoZhtXNFnvUUrOPRIU0BFosg19lAlzAmZDK6r6L6AyXmSBebNNSJ/Fz053kovSzBt2R7OX4uFG0vHp2eAY7equlbMUNI+h0QvO0KRf92URonQMss65QBmWrAp0GmIVVydvopxE97Pyqpxv/wZdgnmCA1Tb+B6jFyuJyw9RXVaJOXqtJfOwLaikAvMUbSYd7O+hRB+DWU2G46z64XA9VD2Sx4lD2XR+LcMPZEeQWnkS98YVTltCMt/CnPCxI6m5GCZw7njgij9NkiBkEsUB4fa9Zp9j0C5R5fLtceyr+tnKZUiRkXQofTdmDRDrWroKMizi1fVucul6jD4viUWyYsia0A4xqNXPsA4WLMEnfNykA+AMQXRZpoWV0im+Ecpk/cKoaGZgSqNvvFH2XcGo4c4TwFqCsBsmemRJLcZvJeWeCGTq7fnJ1xQXeSeXsnBzt2k4jQOIU3NAogednfBbEwVxiCcpTJ3YgS62dJo2E2LqrjFtUUAPFl7GlZ0wW0N1E3yH+SRJ+s07deyRY7YZl2YwJnuM6pvVgl1ky5vc5OWDXX9j5XOl2TY07flCWedGepQqgqh7aCl4YUaSWudsddKZu2N//4hCOSdISxp1CZlOqp6hpOJvo7j4PbZRrAhCL2B+AtFozz8bKeBg5Aq4gbcIdId1FSWaxtJsp3T+xVtsk1OCwDK+zDTjGcIvziYOvQ2v26tHc21y74oXHEXu29xy7wBnvUra+1v1g4L3qLsYkv/F/S1p8hpcRK4DUNhvyJPkaJ0pYouKukSkN8nMjV671qB38RFHNqN/4gDP4Odjs4DO0HIIOLQfbAduPIteDN7vMd/RnYxbAclazNx1n9Xpv/FCXp xPZXGxAR GREY2zmwjnvkzjhbEe+HTUTHLHUSKKF4b80ba62d+z5/8nXfxYyt5zfOOfDiyj6AskvktAlW/FmNAqoa5hcclgj+7f+A6nnCfNz+krshITO4AaJfgx7HofLuvi2XSnB25E4+kx/0w0cV45lTuDcoRZswwEkk88tXegiq14KZE+QxWqNBlRuOU7+kK9L7yDjRHiJ1OAv1r3Wm6tbX6YfgB7TeT0cnm5GJcQIJpONmbLafLsflhEBMWCiuBpzqXd9zrUNbsFLNIWLjj2fauCuNqqnC8vMxdqIH1tch4RDZ/8dyK5j/FNAYX1VWIgQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, 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 11:30:08, 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? yes, this is like any other NOFS/NOIO allocation non-costly (<=PAGE_ALLOC_COSTLY_ORDER) which effectively never fail. -- Michal Hocko SUSE Labs