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 D2E7FC5475B for ; Fri, 1 Mar 2024 20:20:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3FD9294000D; Fri, 1 Mar 2024 15:20:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3ACA3940007; Fri, 1 Mar 2024 15:20:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 29B7094000D; Fri, 1 Mar 2024 15:20:33 -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 1882C940007 for ; Fri, 1 Mar 2024 15:20:33 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 2ACE8A05C1 for ; Fri, 1 Mar 2024 20:20:32 +0000 (UTC) X-FDA: 81849587904.17.4A8D1EF Received: from out-187.mta0.migadu.com (out-187.mta0.migadu.com [91.218.175.187]) by imf27.hostedemail.com (Postfix) with ESMTP id 5C78940015 for ; Fri, 1 Mar 2024 20:20:30 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=YzwdcyT7; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf27.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.187 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709324430; 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=ziC2ak3d9B8hJ8C504tkyb1SDin2zWz3Q5ACLPf5R2o=; b=zMK7LtY1WFczQc+cKbo0CMXAZA8a9klrkoRzjzZigicZTE9J6xwMUjtaOaUj8avUPQJ584 OBl1lEzWJPmEZO1qFg8UTB8Z8gBOaRQurk35SCrxL/wG1r8sb1dNvxyw59KgICa8aVLcEn gUMTLd5l1K8JCc1Ubgg25AFhXdH4UNA= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=YzwdcyT7; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf27.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.187 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709324430; a=rsa-sha256; cv=none; b=pqr8Q8M5BllI/cEnAZqSK6s0KE4IybTd95lDtOQwwtw8+RJsa1CODDQD0jQT9SUF5bhy0k 7aCP5lTY6vtUNZm5JbIv6lLgoSLTiDRd6zFqnDklvpSJeo+MLFntcSrHpaj07qWnynx2NJ RFRuYBOcu9SNnaVTic4FRX48e6hQyB0= Date: Fri, 1 Mar 2024 15:20:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1709324428; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ziC2ak3d9B8hJ8C504tkyb1SDin2zWz3Q5ACLPf5R2o=; b=YzwdcyT7E4f/e+3i6aAmwaz8VLpYJRh2n0RamGMbKTgIHpnc0OXU3PMFjcwFGRdpi0Tki2 XukTeoVnNEwMweK4U/lvH76itLATEB/yWn2iOmJ++l2wokEQ+biiWFYuxCxA6SdvI/7Yhu Cxkubp5lf40v6DwHsS6mPpczUh9Bp8s= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Dave Chinner Cc: NeilBrown , 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 Message-ID: References: <170925937840.24797.2167230750547152404@noble.neil.brown.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: 5C78940015 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: igzcjn91a7uk9xfrafp71m1ez6p3iy3k X-HE-Tag: 1709324430-444331 X-HE-Meta: U2FsdGVkX1+2Q8wj2yttrRr5ps2kR6DIt2cGwGm3QA2/CA3Xiy09pVhVzDJ9eQQSImKuMSMUWtGRlnz1xH/jO2gSfV4DNwRlLFJ2f+BesySErtErCOgpRGdStV21HFqw++/WN/p2SYmuwU6LNwPSTC4gMxVggRogIuFolAiUUH5HWAA4ZRGA79B2rBwuRFAJfl7MjhAFMEniIdkqSEU92AZeizaYu9/T0nlqfICKIIINJpVRUhYaflwFJSjXAWglD6bSTZFrCxvB2xUwQgRUGrtN2kwEMt0ecCKE4CI6vzmgL/3A4p+GnGIli6d79yIWTIC5TLB7xDgwkGFynCmA8XjkGmiexsM78NqzxAxRiFCSEukGDKxXj0J4RThJaLZNciszN1idEp9Ln1iLMIb6t6BREj69x5rQO5yWa+u7lPiwxd0P2l2OL49c2tQCtVrOqEWK98LcM6fGyjWLcCH/MK6AJvsTsc2UObcDXmpot5Cb63ZVTLH56egHoD2OdAZ8w8++51uKVcTWnYxA151M20A4X3pWdc4QmmLzswoXS6xSciABznmpljVITYerdAqqHHbhyiFLf0i6BljnYYxmHHB2ZZRMf2N4MmCHQAvda9knzij3A8lz5xs3gm0upc4YxDD7wgXCBzQ0GptGIQxiJ+GiAIGxQ8MkCca7Yey3Avzxl25YjmfR1HJzN8HWccRVybVrBKYJy6J4TShbVmucxFDAFSDxIWdFIVph8UzOJuP1JrEsaAwWayRpiwG8OhWgXhyQueNZWnHLV5ZObe5clitm1TA9SE9gqTSvHfCX1iU= 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 Fri, Mar 01, 2024 at 04:54:55PM +1100, Dave Chinner wrote: > On Fri, Mar 01, 2024 at 01:16:18PM +1100, NeilBrown wrote: > > While we are considering revising mm rules, I would really like to > > revised the rule that GFP_KERNEL allocations are allowed to fail. > > I'm not at all sure that they ever do (except for large allocations - so > > maybe we could leave that exception in - or warn if large allocations > > are tried without a MAY_FAIL flag). > > > > Given that GFP_KERNEL can wait, and that the mm can kill off processes > > and clear cache to free memory, there should be no case where failure is > > needed or when simply waiting will eventually result in success. And if > > there is, the machine is a gonner anyway. > > Yes, please! > > XFS was designed and implemented on an OS that gave this exact > guarantee for kernel allocations back in the early 1990s. Memory > allocation simply blocked until it succeeded unless the caller > indicated they could handle failure. That's what __GFP_NOFAIL does > and XFS is still heavily dependent on this behaviour. I'm not saying we should get rid of __GFP_NOFAIL - actually, I'd say let's remove the underscores and get rid of the silly two page limit. GFP_NOFAIL|GFP_KERNEL is perfectly safe for larger allocations, as long as you don't mind possibly waiting a bit. But it can't be the default because, like I mentioned to Neal, there are a _lot_ of different places where we allocate memory in the kernel, and they have to be able to fail instead of shoving everything else out of memory. > This is the sort of thing I was thinking of in the "remove > GFP_NOFS" discussion thread when I said this to Kent: > > "We need to start designing our code in a way that doesn't require > extensive testing to validate it as correct. If the only way to > validate new code is correct is via stochastic coverage via error > injection, then that is a clear sign we've made poor design choices > along the way." > > https://lore.kernel.org/linux-fsdevel/ZcqWh3OyMGjEsdPz@dread.disaster.area/ > > If memory allocation doesn't fail by default, then we can remove the > vast majority of allocation error handling from the kernel. Make the > common case just work - remove the need for all that code to handle > failures that is hard to exercise reliably and so are rarely tested. > > A simple change to make long standing behaviour an actual policy we > can rely on means we can remove both code and test matrix overhead - > it's a win-win IMO. We definitely don't want to make GFP_NOIO/GFP_NOFS allocations nofail by default - a great many of those allocations have mempools in front of them to avoid deadlocks, and if you do that you've made the mempools useless.