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 5998CC48BF6 for ; Mon, 4 Mar 2024 01:17:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 81AD36B0098; Sun, 3 Mar 2024 20:17:09 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7CA456B009C; Sun, 3 Mar 2024 20:17:09 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 643826B009D; Sun, 3 Mar 2024 20:17:09 -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 54EBA6B0098 for ; Sun, 3 Mar 2024 20:17:09 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 1AAD7140561 for ; Mon, 4 Mar 2024 01:17:09 +0000 (UTC) X-FDA: 81857592978.05.58D2D98 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by imf24.hostedemail.com (Postfix) with ESMTP id 037ED180008 for ; Mon, 4 Mar 2024 01:17:05 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=RgsW7pz7; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=PR4QviNL; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=rT7LfeyB; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=piU5ZQ4A; spf=pass (imf24.hostedemail.com: domain of neilb@suse.de designates 195.135.223.131 as permitted sender) smtp.mailfrom=neilb@suse.de; dmarc=pass (policy=none) header.from=suse.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709515026; a=rsa-sha256; cv=none; b=SMcZg1ESNlb2KSxtO0OZj+HN50B8knBfRQVpJ+pEpLDngtbS0gM4WOw2aHJKZlD6ARux75 WZ6MntKfv+yqFituwRvAumbj4cA5FYFlklVvj9y1S5bbwvvmPszhMfxz8oW3W+lLy3zSz9 2BZSK7XyehzYYm9ayb1pay2yUjGy3qs= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=RgsW7pz7; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=PR4QviNL; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=rT7LfeyB; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=piU5ZQ4A; spf=pass (imf24.hostedemail.com: domain of neilb@suse.de designates 195.135.223.131 as permitted sender) smtp.mailfrom=neilb@suse.de; dmarc=pass (policy=none) header.from=suse.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709515026; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=6BhzHrZUvZkmoqepVbNm6BaBGGtxilY+mLB34SlnSCI=; b=cGfQn7oFBdkDPiMuXYjydB5FGEVSffLW2ArHBbQcJquuA2if+qKLKtPLJW24+rkyaZb9w2 /x8qWlGuWjcn+d/haus38qh1myNSHVyOx70tbxibe47lWbeHrCXfTrttpbRIzIfUJthECt ujVJKbXG8V0nUQUao3p/dkwHTtrKxO0= Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 39915679F2; Mon, 4 Mar 2024 01:17:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1709515024; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6BhzHrZUvZkmoqepVbNm6BaBGGtxilY+mLB34SlnSCI=; b=RgsW7pz7L5xMrxarCi99vh37/2Z7LDBkMaqbnouG4pCtGA15RJeMdk4HpQh1P00CTfaHC1 K4GJIg37Hi1hZml8TQ4eEtxU/whLoAZaoMPQs4pXMnVRODE1meW/CTRybm1/AO2mRl69fQ jU9IQehD+Q/C8o0xmyto2oPfHv6mX7Q= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1709515024; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6BhzHrZUvZkmoqepVbNm6BaBGGtxilY+mLB34SlnSCI=; b=PR4QviNL9fW30QNqvLsAZQ/S1sUgB/xQ+1K1vZOaAYrOD+eGfoi1aCZGQ/V0Xr1Bx26WU+ Ss32xY8itzt7zODA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1709515022; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6BhzHrZUvZkmoqepVbNm6BaBGGtxilY+mLB34SlnSCI=; b=rT7LfeyBDW84bizhefCkStI4Je4X8OvbixyA+HTFHQaCSJfe7dOdRbOglKT7mxCmaAbzFg Hk2pvl3gq3RB6q2NAbwuuf0U+dVbaUqMPlB4UtjAZLjeMvbFfgstN821Ee23NyMpZI1Ira cVwpHPMOVBFrMs1HLaS0M18ySSbVVyM= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1709515022; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6BhzHrZUvZkmoqepVbNm6BaBGGtxilY+mLB34SlnSCI=; b=piU5ZQ4ACgESro3kyVjdBM0JD8GzsUeaTBqAo/yRPoauS5zxDAHlvofhIfLlFxNn34hG6e 0PQCmosrdRqBvwCw== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 784BC1379D; Mon, 4 Mar 2024 01:16:58 +0000 (UTC) Received: from dovecot-director2.suse.de ([10.150.64.162]) by imap1.dmz-prg2.suse.org with ESMTPSA id J6U2Bwoh5WU8CgAAD6G6ig (envelope-from ); Mon, 04 Mar 2024 01:16:58 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 From: "NeilBrown" To: "Dave Chinner" Cc: "Kent Overstreet" , "Matthew Wilcox" , "Amir Goldstein" , paulmck@kernel.org, lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, "linux-fsdevel" , "Jan Kara" Subject: Re: [Lsf-pc] [LSF/MM/BPF TOPIC] Reclamation interactions with RCU In-reply-to: References: , , , <170925937840.24797.2167230750547152404@noble.neil.brown.name>, , , <170933687972.24797.18406852925615624495@noble.neil.brown.name>, , <170950594802.24797.17587526251920021411@noble.neil.brown.name>, Date: Mon, 04 Mar 2024 12:16:50 +1100 Message-id: <170951501074.24797.10807279234722357224@noble.neil.brown.name> X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 037ED180008 X-Stat-Signature: 95nmc8ieek1wyncjarahxu8kpxhx5s6g X-Rspam-User: X-HE-Tag: 1709515025-713275 X-HE-Meta: U2FsdGVkX1938s7PHhA5gJJyIO9t1f9ZZGe5uNpBclqdj/iakcAzs21aUETTRS8D2et93dOXrFwzZYHmtyIP+5hgmrfrOeUOV9SzLnwHqV5WYATaXN5GJey655zI7YFf8f15zTsJmMVy+5PFCjEWerXvkZf1tDSvzc64uJmakeJICgU0yrMd3nCNp37Yk2Xg88wxso6jQ1OesYRmUjHk0/T7nXZAMQ6Xy76Jin1VYOOWmjl4zcSuumlb3jxJdR6qdAqjcZDbZee8oQXIKaEVvXuqkI/6th38OEZjlq1Qb3Nhjpo5BMmL9W84iQhz8m3x0HDZEDvFKl6MpeLRt5V+H5bJw7pgY3nlAoChMX9XxVxfJpjL1Rjct6cXHeUEAHL26Pp/QGHFYPyN3aCtqu2wxOaefFNUqgQP/GCV5qCawLiLixLD24zgddbhvooJkQ7Myfem/LaBfLncXgUZQb/+IRb+tz4q5upN+zbN0HrxL0jGhvoMj6l6AkDQ56UQtzSSPC0HozekmKRbMAbMLgvUzim5mjetuuumMlY21BOkmCeu2eJ5qJW3E2EW/tMun/GtmZZM1FGqlWFonmht/Y2XqFtk8zqgchu+jgyyVTuuwMmeZLhfH17+XdZupVYxGp+F0kaE9DufvlTxOxaUFiVjTuzykL/xtspfQsKY45C2EKA1Z+mDoA6zc54NsiJiK1q6uEkX1dgS7C0By2YiX+WHxzkfg/I4Fn05o1jwsvFRpzU7sDxicIscSXdOWj/2PPF/qD8G88KdkzmB6a+zTj/FmJ1nmPy01AaNyvwTr+cUaPhyzJpdp3swPV6/5rjzILi1qJuif7al6LxBeaGnDX5cdmIIxkVUpcANUE4Rl/qEyIEZOHgVpqR3UM7dE5sGWSei 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 Mon, 04 Mar 2024, Dave Chinner wrote: > On Mon, Mar 04, 2024 at 09:45:48AM +1100, NeilBrown wrote: > > I have in mind a more explicit statement of how much waiting is > > acceptable. > >=20 > > GFP_NOFAIL - wait indefinitely >=20 > Make this the default, and we don't need a flag for it at all. These aren't meant to be flags - those start with __. They are .. "flag combinations" to use the term description from gfp_types.h There could only be a "default" if we used macro magic to allow the GFP_ argument to be omitted. >=20 > > GFP_KILLABLE - wait indefinitely unless fatal signal is pending. > > GFP_RETRY - may retry but deadlock, though unlikely, is possible. So > > don't wait indefinitely. May abort more quickly if fatal > > signal is pending. >=20 > KILLABLE and RETRY are the same thing from the caller POV. > Effectively "GFP_MAY_FAIL", where it will try really hard, but if it > there is a risk of deadlock or a fatal signal pending, it will fail. >=20 > > GFP_NO_RETRY - only try things once. This may sleep, but will give up > > fairly quickly. Either deadlock is a significant > > possibility, or alternate strategy is fairly cheap. > > GFP_ATOMIC - don't sleep - same as current. >=20 > We're talking about wait semantics, so GFP_ATOMIC should be named > GFP_NO_WAIT and described as "same as NO_RETRY but will not sleep". >=20 > That gives us three modifying flags to the default behaviour of > sleeping until success: GFP_MAY_FAIL, GFP_NO_RETRY and GFP_NO_WAIT. We currently have both __GFP_NORETRY and __GFP_RETRY_MAYFAIL which differ in how many retries (1 or a few) and are both used (the former about twice as much as the latter). Do we need both? Commit dcda9b04713c ("mm, tree wide: replace __GFP_REPEAT by __GFP_RETRY_MAYF= AIL with more useful semantic") might be useful in understanding the RETRY_MAYFAIL semantic. I think the intent is that RETRY_MAYFAIL doesn't trigger the oom killer. That seems like it could be a useful distinction. GFP_NOFAIL - retry indefinitely GFP_NOOOM - retry until fatal signal or OOM condition GFP_NORETRY - sleep if needed, but don't retry GFP_NOSLEEP - AKA GFP_ATOMIC We might need a better name than GFP_NOOOM :-) Thanks, NeilBrown >=20 > I will note there is one more case callers might really want to > avoid: direct reclaim. That sort of behaviour might be worth folding > into GFP_NO_WAIT, as there are cases where we want the allocation > attempt to fail without trying to reclaim memory because it's *much* > faster to simply use the fallback mechanism than it is to attempt > memory reclaim (e.g. xlog_kvmalloc()). >=20 > > I don't see how "GFP_KERNEL" fits into that spectrum. >=20 > Agreed. >=20 > > The definition of > > "this will try really hard, but might fail and we can't really tell you > > what circumstances it might fail in" isn't fun to work with. >=20 > Yup, XFS was designed for NO_FAIL and MAY_FAIL behaviour, and in more > recent times we also use NO_RECLAIM to provide our own kvmalloc > semantics because the current kvmalloc API really only supports > "GFP_KERNEL" allocation. >=20 > > > Deprecating GFP_NOFS and GFP_NOIO would be wonderful - those should > > > really just be PF_MEMALLOC_NOFS and PF_MEMALLOC_NOIO, now that we're > > > pushing for memalloc_flags_(save|restore) more. >=20 > This is largely now subsystem maintenance work - the infrastructure > is there, and some subsystems have been converted over entirely to > use it. The remaining work either needs to be mandated or have > someone explicitly tasked with completing that work. >=20 > IOWs, the process in which we change APIs and then leave the long > tail of conversions to subsystem maintainers is just a mechanism for > creating technical debt that takes forever to clean up... >=20 > > > Getting rid of those would be a really nice cleanup beacuse then gfp > > > flags would mostly just be: > > > - the type of memory to allocate (highmem, zeroed, etc.) > > > - how hard to try (don't block at all, block some, block forever) >=20 > Yup, would be a very good improvement. >=20 > -Dave. > --=20 > Dave Chinner > david@fromorbit.com >=20