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 AE19CC52D6F for ; Tue, 27 Aug 2024 06:40:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 257096B007B; Tue, 27 Aug 2024 02:40:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1DF976B0082; Tue, 27 Aug 2024 02:40:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 080E86B0083; Tue, 27 Aug 2024 02:40:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id DD2296B007B for ; Tue, 27 Aug 2024 02:40:26 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 581391215B1 for ; Tue, 27 Aug 2024 06:40:26 +0000 (UTC) X-FDA: 82497076452.06.CCF7F1B Received: from out-183.mta1.migadu.com (out-183.mta1.migadu.com [95.215.58.183]) by imf24.hostedemail.com (Postfix) with ESMTP id 4A45318001B for ; Tue, 27 Aug 2024 06:40:24 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="MDj1d/+W"; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf24.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.183 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724740761; a=rsa-sha256; cv=none; b=fg7BKCUDkR8Z/+vsft/avY5A6kd/wVXmiplCcrJ+oN5vzVFMyrxL9240a4GZ1R7I1WLUJf D7k8i2iqhhJJgnEWRwt9dKDPNSyxSG/vINMNyzK99t8C26p01v6kdW9oagp0FbL1U5u6hL a4stpYIFpeZsQ0XCZ8l3IFjTU/xOGik= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="MDj1d/+W"; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf24.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.183 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=1724740761; 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=EQptxE7qA2VWIgX3oNQ1mmeqR6GHf9K4w2oDVMxZa14=; b=7/YDX7Kb/1+IOcDbVGXX3RYvhFwe0lXgDeLp5qFQxiD3EBQYYA3Sr0xF8oY7gAA7Zk3Boy XQNnlvR+mEWIjP+mb/AfVp90TV9w7f2rE5jXlad53iELSoZ5jQ/ZOq8bkekozSdgN2jYPf BX39ANu3wl1Ep4uLD+qtDKs+myD5cXo= Date: Tue, 27 Aug 2024 02:40:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1724740821; 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=EQptxE7qA2VWIgX3oNQ1mmeqR6GHf9K4w2oDVMxZa14=; b=MDj1d/+WOS5gCRitsfLH/21htkLMK4K2TIyc1MjdWb4dK3v74eylUATRf/+g4Be72CAJh7 fzv9vUbTA26ve+x7v0o/7FORTyGpY9JqJ7tG7RX0B1mJDSXS3uyYkuxYyVHjkQ7D+uAV3R GAQt+lBjNurKvR3kiN0ZcLosVVtHkqo= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Michal Hocko Cc: Andrew Morton , Christoph Hellwig , Yafang Shao , jack@suse.cz, 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 1/2] bcachefs: do not use PF_MEMALLOC_NORECLAIM Message-ID: References: <20240826085347.1152675-1-mhocko@kernel.org> <20240826085347.1152675-2-mhocko@kernel.org> 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: 4A45318001B X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: wftryz5a3pazikhdpfr57crqu16gqesg X-HE-Tag: 1724740824-128910 X-HE-Meta: U2FsdGVkX1+WCteBa86KpEirTiAErieiWCTUZ+tLGxTq2DlPyTQBs/CdPuqNINujvk3dmhJIWTenqUa+6D2XpbSpeGXV3ufhN9wx4EHe8YYQrQlIXDqMBpn1dWy6HXNpmppP76GqNEMQqS7cpUeTWbqK9B4fqBd/vxn+t39VAO6TBIJOuuqs9opNyhxeMcdBF63nOJ4LN9ksbg3I2TT9fjf4Ij/ibUZiZpViGJYf434QpQVCSTyhvKc0sXaRB/qQVlMThz2tisPFK+uT873jsXFyJ54q7jPqVqHK36NI1IoI7UjqBY50IZcTHwAMWZN7WdHx5uYpWzffZM4WtgWuk943ars+x9IjLFEK37Ys/xcVxu6GvCFPqvu73dSgOXRViZlQcmJ+Bg1IkiO0/jH/gvcqRPNJmr6OFSAxB+MK9cA2VDf66kKim5eKFDVmeQY3mF8ZHM2Ib5geSgUs34GPuKmkG+IPhBpt+KFT0S74ohnu+xoTUAfO7ULtBkaVFbjEacyDEpwbQVTnJnX/1tchHIx/x9BUocJz3t/YnC0ZYF68OQ2V4VNxVxzRMoVksa1WVMCoKvxXUTm5d8wORICC+u2q2h3jzf6LdzoJv+ZUzUohI2IAdN2IB7h7Thpu+gRdsoTS+UEO6rSPboy3+Vfrfg8KDJjj7qflZFtGP//AVIGrgf5gzxqT/jd0lODj9ixJunFyN+YQCzWXpA6DqGf43wxDC07zjdA+qzKbQ+DeHCI+iR9Y0CScahiA0WOwSHA7v/EwL5sjQVtp7Y07qfIyQgUsdcUUWyrFVbaUzFTAxdUBwHmBPaRdkatptRc4DJ4tgYmAI9N0WhxN3LnyOYI3Urbi3A+hU68ikE9QWGk0G0SKEjCeTw5TPoRYZf1lWR5wSOBBHVpDwYsPVU9jeQzt8Q6jurZpK7/0w8wsFwfuGfKeZzSjORTIAxliYxgEIEGYA/hHsxBkut7RjHgUMBO MEEKqx7S wuG63kEEam6NYHqAXL7CZCUyTCuaDJFhGsuAt1gdj3N9erc9WihspljTwlbTdw97vn0y3PikPITeK0nYvP80SsJ+Nl5vh4tUbQHLXeVQ4sr9JGfiz4GHNUGQlFH12hb6ItJUnANSzionw+2uPvk6KE5zDtDxkZ+hkLA4BV7xO1H94NihEUTGEIVSUDqgbmBXARbqaTtvmCsiPIspJAqXmi4EQntf1Azzb/XjGB3xWhKnUXYs= 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 Tue, Aug 27, 2024 at 08:01:32AM GMT, Michal Hocko wrote: > You are not really answering the main concern I have brought up though. > I.e. GFP_NOFAIL being fundamentally incompatible with NORECLAIM semantic > because the page allocator doesn't and will not support this allocation > mode. Scoped noreclaim semantic makes such a use much less visible > because it can be deep in the scoped context there more error prone to > introduce thus making the code harder to maintain. You're too attached to GFP_NOFAIL. GFP_NOFAIL is something we very rarely use, and it's not something we want to use. Furthermore, GFP_NOFAIL allocations can fail regardless of this patch - e.g. if it's more than 2 pages, it's not going to be GFP_NOFAIL. In general you can't avoid having error paths for memory allocations, and GFP_NOFAIL can't fundamentally change that. Stop trying to design things around GFP_NOFAIL. > I do see why you would like to have NOWAIT kvmalloc support available > and I also do see challenges in achieving that. But I completely fail to > see why you are bring that up _here_ as that is not really relevant to > PF_MEMALLOC_NORECLAIM use by bcachefs because it demonstrably doesn't > need that. There is no other user of the flag at the moment so dropping > the flag before there is more misuse is a reasonable goal. If you want > to bring up vmalloc NOWAIT support then feel free to do that in another > context and we can explore potential ways to achieve that. The inconsistencies between what PF_MEMALLOC supports and what gfp flags support are quite relevant. If gfp flags aren't plumbed everywhere, and aren't going to be plumbed everywhere (and that is the current decision), then we must have PF_MEMALLOC support.