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 CA39ECA0ED3 for ; Mon, 2 Sep 2024 22:32:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 106CC8D0115; Mon, 2 Sep 2024 18:32:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 08F8E8D00EF; Mon, 2 Sep 2024 18:32:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E72238D0115; Mon, 2 Sep 2024 18:32:44 -0400 (EDT) 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 C57F38D00EF for ; Mon, 2 Sep 2024 18:32:44 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 2B7B6121D23 for ; Mon, 2 Sep 2024 22:32:44 +0000 (UTC) X-FDA: 82521249048.28.D177B61 Received: from out-176.mta1.migadu.com (out-176.mta1.migadu.com [95.215.58.176]) by imf03.hostedemail.com (Postfix) with ESMTP id 552222000C for ; Mon, 2 Sep 2024 22:32:42 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=umujh2Un; spf=pass (imf03.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.176 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1725316268; 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=CChicL5CaDGtmLSJf1vi34yqR67dtLRNpZXAsSTNcoA=; b=b9xQl1d2t4YKvT9bjc03xDC23O9B0k26Nm4RWWPvUjb65geZEjPnKoCLGOD7qlL94Uqum+ 8ZaZJfPWfKPGxEGWFmD+JtvXg3x4c3srFL/DDSTZubDOGxoF/MDfS8DMv/DmrC04bHSr6r 08rI4TlHQxcIumzfwEgK+7qzjVYE61w= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725316268; a=rsa-sha256; cv=none; b=Ny9p3kKAhjZpswwFXqWO6LIZp9timI2s6lVb9HhNkte7+E1F0Lu71dIk5m5bpMKMOl22X5 JCbgbb2EWM4CyZHGHzIPA3wX4Np+FNcB10oCefdqHs44xs2UlSiFjBWXS0ECnYAY+BiCbo OniEGBN9ALHTQgOe63rHJuERyEou1bw= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=umujh2Un; spf=pass (imf03.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.176 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Date: Mon, 2 Sep 2024 18:32:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1725316359; 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=CChicL5CaDGtmLSJf1vi34yqR67dtLRNpZXAsSTNcoA=; b=umujh2UnaAGmMihjCzRLKqvCZZGmAsBfwXENr0g2sZqZvXzMFKqDXVC1Ve9bQ+0pZkKCnv G0IJqpN17zbRBc90S1MhpC5enVZy8Do2D5jEev27oscgRIne9oKA6WuYDHthrtEWX67Dtk FclhxdraZegGjTP9EWxLPqAW0kENOL0= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Andrew Morton Cc: Michal Hocko , Christoph Hellwig , Yafang Shao , jack@suse.cz, Vlastimil Babka , Dave Chinner , Christian Brauner , Alexander Viro , Paul Moore , James Morris , "Serge E. Hallyn" , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-bcachefs@vger.kernel.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/2 v2] remove PF_MEMALLOC_NORECLAIM Message-ID: References: <20240902095203.1559361-1-mhocko@kernel.org> <20240902145252.1d2590dbed417d223b896a00@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240902145252.1d2590dbed417d223b896a00@linux-foundation.org> X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 552222000C X-Stat-Signature: 73158qr6z6c3xyhwf1ttbpwt7h1qie4g X-HE-Tag: 1725316362-552259 X-HE-Meta: U2FsdGVkX1/d1+bX9nO+ceDuEcadaPsS+2gI3CgsCBGhDnrIArNdSE0eMwAt/fhZ0qQMREP23x869O2zMgFpZAIXYZTM/cEWPJsfAeoPO+mK+OsBaVxKYmyd0GVp4BcgICcYSZRkKyZQUGMYYmgQDqFndxBIgFfowOJLDMqKLowlA78BNhzO4BALbwpusBfRggW0xx3rWd6QwXLP0zomv+LUZKvgPDEOozJL9WHPUaLrwt1jfkD6iz+59VrH2MTUAkjsB2m27/zUa4MwPNnadkEH7bh7/639E75SS/A7nWkY/VylKD5om6KNooEgWPI8vKOCD5hfh2o2fOOVDDPsLBlBa3yLrK9PnyPyUocc6RrQYoYjV73hORIj7RLdGi/o+KAzJebM/7fY7cEDj6EuaJEw0hb9CepoBoZVEoJ7WLc+0H5IllBSVc5cCmvL9/jBazCt3InjRm3bDHAprYCPfKIvkPM2qJMPbJO+L5VZKI+xwrsOljO2vBAEDqNUSZ0JC2dUdUn2MdCHLBu1TpBAHPW5KajaAyMdaOoW/wBclzH5u4inP6lzlg+QwwpUmmFxAJX8QEyMf70cY4gjXNfqvAT/G3WOZSMjAABiM1kW6/p468TB4bl7k6I2Hjg7pLvVv1nKNCC+aGV3Pd70AG9LS4mKzZiWQE1i2SO38kKXEUeDbHVd1FiUIpCauM5NsirK5u/tlNxkGnk4Amj0KllMhpXlVBc2gOn6nUFjHTsFx73yxug8+cdUkFe4Yw6C+KaEkDc37Zr/3g5SWOVY5GNJucrffQVipx/WI4mkY3H/c3mzgksn92YA8QTwLJN4IXllPGkI5BdGhjT9TimD4VQqdI5yzqJmMpSPkheICC5QLtUg6WhFD8TtCu2kAF2vBifsCnCDos6a/T9x4zq6aS7mpqf+04NVXDc5csjA5qlaZZJaR/t0imirFuoiMkzfQkPLyAvNITzIoM0euxF+hGL H2ys3ts0 RINy8+T6zSeWqJAJY82uCP6Og14snjcndxRi48BNFK6LgnfoFZCdNXf94LQu9FkHvFnsxOADWnkArXJa4PjGXtKD9si1dTf22ay3G3NWNBp+O8d++v3deeky3yWwDyDe0DwBJBmWO0M63SbZ0u2iIknmMFHjW0yIaXizY7x/8fxvpVriXkYf6DGZYLZqIX+lWYzrhkllhrj0QRn7+LxjsFvrNSC8BMkw7kdCIjohFSLuiQp4pk/SScRLnXnqgn3EJDuJkIB3vtnxLLs8= 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, Sep 02, 2024 at 02:52:52PM GMT, Andrew Morton wrote: > On Mon, 2 Sep 2024 05:53:59 -0400 Kent Overstreet wrote: > > > On Mon, Sep 02, 2024 at 11:51:48AM GMT, Michal Hocko wrote: > > > The previous version has been posted in [1]. Based on the review feedback > > > I have sent v2 of patches in the same threat but it seems that the > > > review has mostly settled on these patches. There is still an open > > > discussion on whether having a NORECLAIM allocator semantic (compare to > > > atomic) is worthwhile or how to deal with broken GFP_NOFAIL users but > > > those are not really relevant to this particular patchset as it 1) > > > doesn't aim to implement either of the two and 2) it aims at spreading > > > PF_MEMALLOC_NORECLAIM use while it doesn't have a properly defined > > > semantic now that it is not widely used and much harder to fix. > > > > > > I have collected Reviewed-bys and reposting here. These patches are > > > touching bcachefs, VFS and core MM so I am not sure which tree to merge > > > this through but I guess going through Andrew makes the most sense. > > > > > > Changes since v1; > > > - compile fixes > > > - rather than dropping PF_MEMALLOC_NORECLAIM alone reverted eab0af905bfc > > > ("mm: introduce PF_MEMALLOC_NORECLAIM, PF_MEMALLOC_NOWARN") suggested > > > by Matthew. > > > > To reiterate: > > > > It would be helpful to summarize your concerns. > > What runtime impact do you expect this change will have upon bcachefs? For bcachefs: I try really hard to minimize tail latency and make performance robust in extreme scenarios - thrashing. A large part of that is that btree locks must be held for no longer than necessary. We definitely don't want to recurse into other parts of the kernel, taking other locks (i.e. in memory reclaim) while holding btree locks; that's a great way to stack up (and potentially multiply) latencies. But gfp flags don't work with vmalloc allocations (and that's unlikely to change), and we require vmalloc fallbacks for e.g. btree node allocation. That's the big reason we want MEMALLOC_PF_NORECLAIM. Besides that, it's just cleaner, memalloc flags are the direction we want to be moving in, and it's going to be necessary if we ever want to do a malloc() that doesn't require a gfp flags parameter. That would be a win for safety and correctness in the kernel, and it's also likely required for proper Rust support. And the "GFP_NOFAIL must not fail" argument makes no sense, because a failing a GFP_NOFAIL allocation is the only sane thing to do if the allocation is buggy (too big, i.e. resulting from an integer overflow bug, or wrong context). The alternatives are at best never returning (stuck unkillable process), or a scheduling while atomic bug, or Michal was even proposing killing the process (handling it like a BUG()!). But we don't use BUG_ON() for things that we can't prove won't happen in the wild if we can write an error path. That is, PF_MEMALLOC_NORECLAIM lets us turn bugs into runtime errors.