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 F2B62C54E5D for ; Tue, 12 Mar 2024 22:10:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6BDC58E001E; Tue, 12 Mar 2024 18:10:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 66D048E0011; Tue, 12 Mar 2024 18:10:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 50CEE8E001E; Tue, 12 Mar 2024 18:10:02 -0400 (EDT) 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 438928E0011 for ; Tue, 12 Mar 2024 18:10:02 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id EA9B31601B5 for ; Tue, 12 Mar 2024 22:10:01 +0000 (UTC) X-FDA: 81889780602.10.A72B604 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf20.hostedemail.com (Postfix) with ESMTP id 982C81C000C for ; Tue, 12 Mar 2024 22:09:58 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=WRBcpldV; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=+m1lanxo; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=WRBcpldV; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=+m1lanxo; dmarc=pass (policy=none) header.from=suse.de; spf=pass (imf20.hostedemail.com: domain of neilb@suse.de designates 195.135.223.130 as permitted sender) smtp.mailfrom=neilb@suse.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1710281399; 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=rnhnvuAguaShvZnqnUxmnsYkUTMmDsH7p0cA6XDgY/U=; b=Kme6GSe0ey6yl+NCPzpNNDUxsYLSWo9HwbG5jESJdSXq26YNNZBre5vn3vfjhskWBAJEC1 554nU4uMOcW76shmiyYS8Q5LIbk3f/48sFhHDf5473uZhv8/Y7CfJcj4KUir0v1vDrR9+R TdIw5eBoQjHh5QUMMaHwu2/jnqH9hFQ= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=WRBcpldV; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=+m1lanxo; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=WRBcpldV; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=+m1lanxo; dmarc=pass (policy=none) header.from=suse.de; spf=pass (imf20.hostedemail.com: domain of neilb@suse.de designates 195.135.223.130 as permitted sender) smtp.mailfrom=neilb@suse.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710281399; a=rsa-sha256; cv=none; b=rZl4rIFKIy/ce+UR7INUuyP2Y2RWnYxR5OoF6Sr04DqTrpttlGcjDETp8EyIWubHvloySY iAM9UQZWhzVw8LiYMqQdaGlhOG0p4UIOM/2QyepHfsrl8U4Nvl+P9K6JmaVlT+bl6scl7O rXAdYqgNK6SKl+mZ8UMGG4IKg7fLzvA= Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [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-out1.suse.de (Postfix) with ESMTPS id B052221BF8; Tue, 12 Mar 2024 22:09:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1710281396; 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=rnhnvuAguaShvZnqnUxmnsYkUTMmDsH7p0cA6XDgY/U=; b=WRBcpldVLBNeFN/rOJ5oOkzmrfstQVpSJ8V1Re7qSwyXK4W98THjh5+slt3isMEYE7vai0 EcxNV5rBTGkL5kaH28V6naF7drLF9lGlgPNVPp3tQBFrV5bvBwfvJ5GxWt3uHnEjmXEPc2 tajOyKLYL4JdYd37MZQ+MkcJUjuxXQ8= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1710281396; 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=rnhnvuAguaShvZnqnUxmnsYkUTMmDsH7p0cA6XDgY/U=; b=+m1lanxoZbPHWDQLSDFeL9FMF23WRPwPKdTO8XjmZlayF1oGe2Ka2LpJbCuLoA1wXPBDNc T7Ocf7tRrYQRSeAw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1710281396; 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=rnhnvuAguaShvZnqnUxmnsYkUTMmDsH7p0cA6XDgY/U=; b=WRBcpldVLBNeFN/rOJ5oOkzmrfstQVpSJ8V1Re7qSwyXK4W98THjh5+slt3isMEYE7vai0 EcxNV5rBTGkL5kaH28V6naF7drLF9lGlgPNVPp3tQBFrV5bvBwfvJ5GxWt3uHnEjmXEPc2 tajOyKLYL4JdYd37MZQ+MkcJUjuxXQ8= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1710281396; 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=rnhnvuAguaShvZnqnUxmnsYkUTMmDsH7p0cA6XDgY/U=; b=+m1lanxoZbPHWDQLSDFeL9FMF23WRPwPKdTO8XjmZlayF1oGe2Ka2LpJbCuLoA1wXPBDNc T7Ocf7tRrYQRSeAw== 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 8E4261364F; Tue, 12 Mar 2024 22:09:52 +0000 (UTC) Received: from dovecot-director2.suse.de ([10.150.64.162]) by imap1.dmz-prg2.suse.org with ESMTPSA id n0CEDLDS8GVkNAAAD6G6ig (envelope-from ); Tue, 12 Mar 2024 22:09:52 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 From: "NeilBrown" To: "Vlastimil Babka" Cc: "Kent Overstreet" , "Dave Chinner" , "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: Wed, 13 Mar 2024 09:09:44 +1100 Message-id: <171028138478.13576.3004333623297072625@noble.neil.brown.name> X-Rspamd-Queue-Id: 982C81C000C X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: u954iinmuewdkayzcre4rxthrdup7cp9 X-HE-Tag: 1710281398-113328 X-HE-Meta: U2FsdGVkX1/j0x8dbGiiq6Q1zJpDH+436+8Q+NlRUATFV+Q2svJRUmCTu5Znz5u4y8sGG4+GzIrRdg7QoKD5o8xUWOSdy6iAVlfafA0SMw5ecnRUIC07mN9DtMkXVHq0CvymiK3UJpj8SLwpzlwzyo1w5kJQZRKKa8awrxZhxvf3g2kBiE1i1HJg8Wkv8mY/Zl+EFMrVwsaPTH+oelDrKlfPawta73niXQmWDPfHa1djDffrebJpMPHK7V4ee8LDfjESNtBscyDBtwE94dq87Ir7+UTW4QNVIMpLKOYzpp62zy/uePrgsq+wGa8rYNEqjfT9tZFukYi1KHRIA8CNGZfyQWbNkTGCbvZkdsfUcA+6PtmJY4a2OTjcPT9x5BEjYnFnhL/TjwFXL6l9HltDI4qVxMKxIy1ksohF05BD0GqV/aynNwkQX09bOLcRuzpKWx+2k42MDzXW5NluLzo07YjxN8MJOa7KErj/G8QnTqSNRyqDBOkItJw4+sj1IjuOpBDNWJUG3atb+IQJWuyKIY+hKAvKeOoJHZQqL+bHoNcgitVALGSHVXGmr4R6lrxSwm9woCOxjQmXoToyh2DH0v+M8+7/pvniJeQhpc86eMc+nUn6cOMM1Zb4xwpF1xlIiZVu3wxXLaJc/bkseB5SYemEKhwI3bLYktzKVxnrw8725VdMlci7BKsC2aWUUckmHKvafIWBxUFbIdsPOtHMf1C++vIR0Nku1Llf6AlrO03cZp03fKMzkO5lO4SacNxKT/l79vEQHBvikd+mIJiarEEyivf7CwoJXjTDpcEeRMl4EhLz5NktbNnlEFaorHfeEvy2oLGBGTUl6i8rlmIKtyaLq03s4iRNpNNgdLRkU3h5gvHK760X1TDq3Iw4aP7Kfa5/l92C9piHEfDOpDgQN595I4WAu+IJM8WThK2Xiy13nkN1tPIkPpXSa2KYfqC9hB0UyrkP15IoY2UmmEZ EonL08wN MElWg61KU4PSlQ26RNNUrAKIexAZjEqOY+8niXJwV7qhu2Vyc2sKPUluRNkZNvuWW7oogbqzUODZoUE0uILqlYzlUy5qqAyaSXMVRiXdlInqRnUqFK62nZPWCsxUgvkdhxP59jbe6EH+D0WJi+cTtiszNACdKnNwg7/tSSsbfmoY/Ur8bHf6/7HEJnb7xxVB54cFy6GMDl1oK5mg= 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, 13 Mar 2024, Vlastimil Babka wrote: > On 3/3/24 23:45, NeilBrown wrote: > > On Sat, 02 Mar 2024, Kent Overstreet wrote: > >>=20 > >> *nod*=20 > >>=20 > >> > I suspect that most places where there is a non-error fallback already > >> > use NORETRY or RETRY_MAYFAIL or similar. > >>=20 > >> NORETRY and RETRY_MAYFAIL actually weren't on my radar, and I don't see > >> _tons_ of uses for either of them - more for NORETRY. > >>=20 > >> My go-to is NOWAIT in this scenario though; my common pattern is "try > >> nonblocking with locks held, then drop locks and retry GFP_KERNEL". > >> =20 > >> > But I agree that changing the meaning of GFP_KERNEL has a potential to > >> > cause problems. I support promoting "GFP_NOFAIL" which should work at > >> > least up to PAGE_ALLOC_COSTLY_ORDER (8 pages). > >>=20 > >> I'd support this change. > >>=20 > >> > I'm unsure how it should be have in PF_MEMALLOC_NOFS and > >> > PF_MEMALLOC_NOIO context. I suspect Dave would tell me it should work= in > >> > these contexts, in which case I'm sure it should. > >> >=20 > >> > Maybe we could then deprecate GFP_KERNEL. > >>=20 > >> What do you have in mind? > >=20 > > I have in mind a more explicit statement of how much waiting is > > acceptable. > >=20 > > GFP_NOFAIL - wait indefinitely > > 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. > > 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 > > I don't see how "GFP_KERNEL" fits into that spectrum. 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 > The problem is if we set out to change everything from GFP_KERNEL to one of > the above, it will take many years. So I think it would be better to just > change the semantics of GFP_KERNEL too. It took a long time to completely remove the BKL too. I don't think this is something we should be afraid of. We can easily use tools to remind us about the work that needs doing and the progress being made. >=20 > If we change it to remove the "too-small to fail" rule, we might suddenly > introduce crashes in unknown amount of places, so I don't think that's feas= ible. I don't think anyone wants that. >=20 > But if we change it to effectively mean GFP_NOFAIL (for non-costly > allocations), there should be a manageable number of places to change to a > variant that allows failure. Also if these places are GFP_KERNEL by mistake > today, and should in fact allow failure, they would be already causing > problems today, as the circumstances where too-small-to-fail is violated are > quite rare (IIRC just being an oom victim, so somewhat close to > GFP_KILLABLE). So changing GFP_KERNEL to GFP_NOFAIL should be the lowest > risk (one could argue for GFP_KILLABLE but I'm afraid many places don't > really handle that as they assume the too-small-to-fail without exceptions > and are unaware of the oom victim loophole, and failing on any fatal signal > increases the chances of this happening). I think many uses of GFP_KERNEL should be changed to GFP_NOFAIL. But that ISN'T just changing the flag (or the meaning of the flag). It also involves removing that code that handles failure. That is, to me, a strong argument against redefining GFP_KERNEL to mean GFP_NOFAIL. We (I) really do want that error handling code to be removed. That needs to be done on a case-by-case basis. Thanks, NeilBrown