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 C3EC7C46CD2 for ; Tue, 9 Jan 2024 04:47:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1B4E86B0075; Mon, 8 Jan 2024 23:47:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 163EF6B007B; Mon, 8 Jan 2024 23:47:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 053896B007D; Mon, 8 Jan 2024 23:47:47 -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 EA83B6B0075 for ; Mon, 8 Jan 2024 23:47:46 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id BC5371A0771 for ; Tue, 9 Jan 2024 04:47:46 +0000 (UTC) X-FDA: 81658539732.25.2AE3C7B Received: from mail-pg1-f169.google.com (mail-pg1-f169.google.com [209.85.215.169]) by imf18.hostedemail.com (Postfix) with ESMTP id CA58A1C0002 for ; Tue, 9 Jan 2024 04:47:43 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=vGY74BQy; dmarc=pass (policy=quarantine) header.from=fromorbit.com; spf=pass (imf18.hostedemail.com: domain of david@fromorbit.com designates 209.85.215.169 as permitted sender) smtp.mailfrom=david@fromorbit.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1704775663; 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=/9d1a6daFwQBP+JMhfWhKWCeVA+a5Q2tDHFKvp5Evgc=; b=7UyTVI1VSvcf1jkImAdOHsna4A1g4xy5C7TXAHkFCp8/joJIwm9VNeMDnWQ79rmmJZO/dR wZDUBD5A8xNWJSFL1/T3j8d6vL9Vi2yN9Y9EtB2HehAgrxrie1rbotkTMP++jePrW9Xzyu xBsr24munmx4YApVXNOjTCtYktgD1VE= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=vGY74BQy; dmarc=pass (policy=quarantine) header.from=fromorbit.com; spf=pass (imf18.hostedemail.com: domain of david@fromorbit.com designates 209.85.215.169 as permitted sender) smtp.mailfrom=david@fromorbit.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1704775664; a=rsa-sha256; cv=none; b=Eob+9YBaFIlEWfZBFA6gvlJVjKzn5Zx8EOHRCI1Qy+5sZx3k5FyiJpPBCTRJ7gzyqYRG2B 7heQU701Up2YZwuJ2VV8gSYxOjp2JTgd9fhOOjyojx9SKO4XEUJbMRpzy1PxT4/hQnzYiR W57dT5MgBzOcbDKl7uv1iwrm18TD+8c= Received: by mail-pg1-f169.google.com with SMTP id 41be03b00d2f7-5cda24a77e0so895763a12.2 for ; Mon, 08 Jan 2024 20:47:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20230601.gappssmtp.com; s=20230601; t=1704775662; x=1705380462; 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=/9d1a6daFwQBP+JMhfWhKWCeVA+a5Q2tDHFKvp5Evgc=; b=vGY74BQyn28Ic6vrfE4gXsMliQnYAoiagK34OpGMYHBnN3NEAth3pjY/Vwuj788ExS nbR087jLpZgTbYNyvamyl9CYRc28vgoPPrn4fdPu1zRVg0tohBOap6u2wBQSpwbNqSJB uMFlzkmdINhRk7kQO1y5dvtiEDWwyUNc55OQ7ves3BKcTp0WvmIqg4rmHT5bnUn/8mci h2s8rylhArkaGFFd1HBBTc0sLHGrbvLxaGGub2MEEtAJiyITE/D8C2QayN3oTOgwsSuA Wnh6NxNkIXeijZtaroY6M3PPPdPqv9C3TkLOJBkZeRm8AgLipMDf0E9OEQH5Hy222jvC WHDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704775662; x=1705380462; 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=/9d1a6daFwQBP+JMhfWhKWCeVA+a5Q2tDHFKvp5Evgc=; b=wgVagWOPEYYyqdcaRHmWtUqYcvOsBJeQNM7sdJCSG5y84egw/kMlri5P1gLj45T2To 82qgpYIKN8adnPB8iCVQ/HV43S9K+KP03e0yRBqURIJFNsIRBBXyoVtT1Tx02Zjvy0gA 4Kb87H+YsGrBpd4ZiCkMT/8aSrk4BzBIZ0GGe2w8b0i/mBfLGs2nnOe9yFTal88MowHQ 0qM6g9daXCa0iZF5ST70UPTflhL9lqIw8NY2jeQu9r0mtRLMahXA9vcWBKBiluhqUOCb iRKbtA8+SzOdHknoCYJvZ7mnMjIGsdwVrX6tKG7Otm0ZXpavXDUMJIU3loKtYEG+nS4x UXQQ== X-Gm-Message-State: AOJu0YzeUVjqyO87ddWAmf1Vz4zOm7KYvLPhy9VhhareA4h4E56ZSvNJ cx9XoO93M9Cz0TSyV9+8xngAhUWYFPHXgA== X-Google-Smtp-Source: AGHT+IEXGWamsR7Yytcu+DAmr0p08k3oitSFEY8voIlETwQIHC6HU43wCVNAvJQUiECekKewVk/oIw== X-Received: by 2002:a17:90a:4b8e:b0:28c:a5e2:1652 with SMTP id i14-20020a17090a4b8e00b0028ca5e21652mr1845080pjh.12.1704775662422; Mon, 08 Jan 2024 20:47:42 -0800 (PST) Received: from dread.disaster.area (pa49-180-249-6.pa.nsw.optusnet.com.au. [49.180.249.6]) by smtp.gmail.com with ESMTPSA id b6-20020a17090aa58600b0028cf59fea33sm812372pjq.42.2024.01.08.20.47.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jan 2024 20:47:42 -0800 (PST) Received: from dave by dread.disaster.area with local (Exim 4.96) (envelope-from ) id 1rN41b-007vgb-0Q; Tue, 09 Jan 2024 15:47:39 +1100 Date: Tue, 9 Jan 2024 15:47:39 +1100 From: Dave Chinner To: Matthew Wilcox Cc: lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-block@vger.kernel.org, linux-ide@vger.kernel.org, linux-scsi@vger.kernel.org, linux-nvme@lists.infradead.org Subject: Re: [LSF/MM/BPF TOPIC] Removing GFP_NOFS Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: CA58A1C0002 X-Stat-Signature: nfspgyf8ryms1j7jwo8q4n6w474pj7kx X-Rspam-User: X-HE-Tag: 1704775663-992646 X-HE-Meta: U2FsdGVkX18iKKZlVnlCgtXoq3Gmm2uiCo7cZm1qUnh3giBaVsy/mH2msjIQLj3oLpXoHbXUV54pCpD41sfVhqx9YcUFogr+mf/JZ6ZERBuDfn3Y6ZGvsAOX3aHt7qP9zbU59HNvFS1sG2pwzBXRZXDK8Qowf5yN7DZK5kiZ/hqAx7JAsfufS56cmhvzGhhrkrNXmxF91788mYfMjOCLTWDv0OIZmKTINNFccrwpJpWxDUhS78AX64IgKcujCQ6xW1BH5A88eENqaIBh44oR88DXi2/PGgegwEIIIF/lTN2E5H1nRVb8z2hLifmvK5mMgDPNAHjTdFna4EcbgpisXzotdCU0Pitq/nz22mITeKATfTzHXyMThkaTWMdw8ysYfJp4ka43N4hDaCugGzgWwBB4KOlStB8Ci39nETx6XGmDdMntZvYOcZtWm1N2gSh0PDFUQ1qyTE5BuuUE6QtpuZB5Px0bQUB7vGO/fKrrDyEBbynuECOioVZdKh3Qh7vodU5sdlMiV3FHDLRswC15tbAuuPj7YYCafxu6k6E8TMRe7dYCY/RNPCfRhz43/GBt4yRe/XUnIXr+YNd5zrgY9XpqKgmShy8ZiANdl8TuTX83EvnJh0GwK/ImdLVIo7WBuOpJ7oqNOrSkX5F0417IvG/biWG1B0KF4ZHKe6mCNtXAjOHIDL8X57hn1FVoR1YnJsGwEpMBWUBaQIKx15/R+SfGLtgxPen1RFwFhEhKFAipaGbk/oTWPDd/R1pWLDRoudOp+3u8kqZYyjuQN9+3HWxLYdUbQuljYDQjqCs09I0tURAJWO4haLV5qdsNjaQilqllRpq+wv0CP5cPdB4bUhV00YU05N1b32BB48kRnNxVBBEDdaYpx4DdOR4g4r3Mgavt4XUPgXmsk2N5R1hQvpoHzDMBbIoM6M/lCld9oO5P42oFD50SeTc8tiA711ZNUOdR1SXsSJZVKKJ/q2w h8TA1QE5 nANDE35obTJIHBmtaMKgjYzoQZ3GK8K/Wf/JUxQoIFW1C36XpRXsXVaHs6HbcOPkpXRCyEKhr7VA+LW2HvWvVGbhncR9ndpRB8aQk717E/VVzNW/DQpmLOCj6U4h4fcCHlNe32rzCiFNw4qlSXo0q6gZG0bQ2laXWCc4ndRCiO5Q+g1EBxtpewVyejO/a0cW7HvVIqT5+ce1Sd4zAsia1kjZvQsaiAbCLXT6ghjH7oxEtqcxWkgstrsW+G87+Fa2gVoz36fwwUgIstq325LToJyrsmRzl4V/n/bAW+jpSvHHwPzEEh8j+4BhAvCumg4Oiu8dlbO3t8vS9Fiaun34pnz8LoZyAsg5F1QX3Y/sVNXdID/4SvCd9YQHmAVQpw5QTKddsvmu9S2OhYaceT7k+6uu28I3+tzEAvz7KXThu/dOMkDf65RB3tFB47vmQrCyOrQugk8MalZDI1EuD6psFT5seoV0u/zk0uj8s+S+kCQFw2TVufG1k7bm/0e7AkXU8YITRrDh0b78Daixw8pJ3Idm6BtEbERreqMZI 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 Thu, Jan 04, 2024 at 09:17:16PM +0000, Matthew Wilcox wrote: > This is primarily a _FILESYSTEM_ track topic. All the work has already > been done on the MM side; the FS people need to do their part. It could > be a joint session, but I'm not sure there's much for the MM people > to say. > > There are situations where we need to allocate memory, but cannot call > into the filesystem to free memory. Generally this is because we're > holding a lock or we've started a transaction, and attempting to write > out dirty folios to reclaim memory would result in a deadlock. > > The old way to solve this problem is to specify GFP_NOFS when allocating > memory. This conveys little information about what is being protected > against, and so it is hard to know when it might be safe to remove. > It's also a reflex -- many filesystem authors use GFP_NOFS by default > even when they could use GFP_KERNEL because there's no risk of deadlock. > > The new way is to use the scoped APIs -- memalloc_nofs_save() and > memalloc_nofs_restore(). These should be called when we start a > transaction or take a lock that would cause a GFP_KERNEL allocation to > deadlock. Then just use GFP_KERNEL as normal. The memory allocators > can see the nofs situation is in effect and will not call back into > the filesystem. So in rebasing the XFS kmem.[ch] removal patchset I've been working on, there is a clear memory allocator function that we need to be scoped: __GFP_NOFAIL. All of the allocations done through the existing XFS kmem.[ch] interfaces (i.e just about everything) have __GFP_NOFAIL semantics added except in the explicit cases where we add KM_MAYFAIL to indicate that the allocation can fail. The result of this conversion to remove GFP_NOFS is that I'm also adding *dozens* of __GFP_NOFAIL annotations because we effectively scope that behaviour. Hence I think this discussion needs to consider that __GFP_NOFAIL is also widely used within critical filesystem code that cannot gracefully recover from memory allocation failures, and that this would also be useful to scope.... Yeah, I know, mm developers hate __GFP_NOFAIL. We've been using these semantics NOFAIL in XFS for over 2 decades and the sky hasn't fallen. So can we get memalloc_nofail_{save,restore}() so that we can change the default allocation behaviour in certain contexts (e.g. the same contexts we need NOFS allocations) to be NOFAIL unless __GFP_RETRY_MAYFAIL or __GFP_NORETRY are set? We already have memalloc_noreclaim_{save/restore}() for turning off direct memory reclaim for a given context (i.e. equivalent of clearing __GFP_DIRECT_RECLAIM), so if we are going to embrace scoped allocation contexts, then we should be going all in and providing all the contexts that filesystems actually need.... -Dave. -- Dave Chinner david@fromorbit.com