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 66F5FC48260 for ; Thu, 8 Feb 2024 19:55:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A6CA16B0081; Thu, 8 Feb 2024 14:55:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A1CBD6B0085; Thu, 8 Feb 2024 14:55:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 90BF56B009A; Thu, 8 Feb 2024 14:55:13 -0500 (EST) 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 8302D6B0081 for ; Thu, 8 Feb 2024 14:55:13 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 505A51407D1 for ; Thu, 8 Feb 2024 19:55:13 +0000 (UTC) X-FDA: 81769690506.06.735FE0A Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf13.hostedemail.com (Postfix) with ESMTP id 83A4020019 for ; Thu, 8 Feb 2024 19:55:11 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=fHFRsg6W; spf=pass (imf13.hostedemail.com: domain of vbabka@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=vbabka@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1707422111; 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=fsPJ5omAsHbebGoKAX+m54ZzUdjULnFYtbhcZzgcDQw=; b=bSr6hAYENOz7lT+F3saTm/XIsf8LEEdQ9Qri3+C+I47kK1Bk+eXilDhlxqiTkl93bftzFC k+s3pRC5YUIRVHBWZUKn1aR8iZtUqoZy91MIATabFmBHrHsmj7HIZN7afp+c6ohyTxCMRx pLq8Bti+tnt7xG5Uskk41AXllYr5a8E= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707422111; a=rsa-sha256; cv=none; b=dqae937d/UvT6wUPf8meu+2jZnxx6/oAAGr7Vz1Rs0xUP9QkfX6bQObX2WRlzgxVQyeyde zN83uxLQPwRXpeo/GGtnPcFBRh/MymWJo1D7D5nZ4fUMWHVh45RbGq7EXCKbolh47BpeUt ObPfu7KrVvaP678ptbYOoOO1AK4Ht5g= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=fHFRsg6W; spf=pass (imf13.hostedemail.com: domain of vbabka@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=vbabka@kernel.org; dmarc=pass (policy=none) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id A536961EE1; Thu, 8 Feb 2024 19:55:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2C640C433F1; Thu, 8 Feb 2024 19:55:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1707422110; bh=lOfJwpXUdnEs4NdD2l4UxOLwSgcIGRsZp7hL7KAWBwk=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=fHFRsg6WccEchUFyrMTDbpsND8UtEeB7G2dQt7WSwW8EOSdvsfxtiFUpL1Bdc8Bek mh+UH3E7pdkOXekpzAzB2Pte0DAjqeQI7oJCq5r591oq0M4sd/i3vPYbBzncVnNDqg VdQaxpWDwOL96HRfsQNAt52NDO1G0JOuNMlGofKNd9hhSd8oBzVG7s6bJ8A8fR5LBJ yysBINVtEdH6Xnc0eqoSx/ALVkQLvXDJRAk7TG96ukqW5tcoESko0YM4DQ9pryNltg B7qluL+vCL/+79c0MwGCki1auhtFUIYmiLQZ3ztfxrpEONfxrA79RQpZ5zr/curMdQ h/meCLWH4APjQ== Message-ID: <3aa399bb-5007-4d12-88ae-ed244e9a653f@kernel.org> Date: Thu, 8 Feb 2024 20:55:05 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [LSF/MM/BPF TOPIC] Removing GFP_NOFS Content-Language: en-US To: Michal Hocko Cc: Dave Chinner , Matthew Wilcox , 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, Kent Overstreet References: <3ba0dffa-beea-478f-bb6e-777b6304fb69@kernel.org> From: "Vlastimil Babka (SUSE)" In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 83A4020019 X-Rspam-User: X-Stat-Signature: h4b8z4wfsikk88ejzndsgrmhb9e4orkp X-Rspamd-Server: rspam03 X-HE-Tag: 1707422111-725182 X-HE-Meta: U2FsdGVkX18JzksIuwWgJoTjFHrupNd0TVo0fvX4gGAhNJ6WE4lXPcyBz1YMlgtrUCpr9Jl5YVvOXBY0WUCj/WqUwGi2ORKYrdL1UQ35UVhbLT6QoUTbUcJWFOjyPnZAPiD+8C2I8oM8fe5q6oT3XIcc887iEy08ffN4bRUMYDKLywijQ23+onFbBjGriwYB4FdhzRR+V3m1dfQI8ZPwCj97m/9X97Uof41FceGcFRprbUVygY4lV7O33cbHmuLAeskElp46NnX+vDoi7zouiax7DU26rPpmx4ImIWvgcxgawR5QaI9zKevYnvkrAf7FKvEK2hG7HwGUnS6JyIKZPVoXB1O163GE6v3ycJVIsTnL0HPtVsiPQRVFyF75syFfZbraYxJ2HXVUVQkz2+yNPWlBQiVq6SlXXFw48OLDJEaxMpngOJ+e29bGSkXN940iCPbwRwrvRgXFU1gA/tmT7c0WK0LYWd0FFyFH2YJA46rBtdikBcB4WLaf9ei64OYzdZMx3G7WpMYl130iwvnbBvucVWUu4hLKyQ8kaZd4zw1WDSwRBTeSp8O9nhAFwlr0CYF5tEQi1b2Q1pgwRuiRX36ja8vTJq9w89BMzWZJq/BLl9UQ8vBPdRWZ2epjmh544Za9z4TeoW507pKproNx3NQaUm1qMdtJZAKQUeYoQQ1xgAowIQJyf9PGVSVP4xSludxa8cIDopq/7uTmhhpjCHdMoTOd7a+lC3655hobX4QK2cxqkjAOJpS1DE/jRsQSqfx6q0PYUBgIvNkkUbThDwnjXjwfnbrlbs6F9YlYsHgXAegpbTOgtaPT0XznS2X4mnkO9Mtmn0OTI3IWuqkC2WK1YJuw6c03jEg7K7DYrsRK1U5Xc7QknLJb09oznGGjYfBQScV1dHEwGwrk2pRKQfveLt9Q24DRh8Fv6N9mRkWoy6aZKyFPP+mwQ3j3p/yfNns63WkQhUhmFAvgOur WhlUGv8o LJXOg9rl8Xdvg6S9+CA0aD1E4ULV/lzcwfbbJypMeYX2IUxeZ7O1YdVn+bWMrGaqdzSjzzxO19BXeuvi+6j6N+hWn+EnxWY/7GQcxBT6soqD5epkL7vcZxKH7ro5x+GAXJzMmdBZrcKeH/TmxuQg7syiNb9g8HBFaYq2YqTi34sdS76/DJUmCFVN2aMvHyeFcaRZpVbktmanZsRbP/aBZt7qBE2Q1XG/orBvQGxZggH93IUnUwQ63LUFkr1fo5van6O/9BbJ3/+2N1lHdPxOkYZv1/dce3muF9Y+thGfjbyMn5gM0RjeKiTxaSxlbBYybWYspRr4LmRVAhPhvsDbXq2BnTVpgiH5aH7vqAIoCbvUQxLdypeGOl5Wt87US85+gQfAnepNC43E+VYNaccwO4NKOgg== 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 2/8/24 18:33, Michal Hocko wrote: > On Thu 08-02-24 17:02:07, Vlastimil Babka (SUSE) wrote: >> On 1/9/24 05:47, Dave Chinner wrote: >> > On Thu, Jan 04, 2024 at 09:17:16PM +0000, Matthew Wilcox wrote: >> >> Your points and Kent's proposal of scoped GFP_NOWAIT [1] suggests to me this >> is no longer FS-only topic as this isn't just about converting to the scoped >> apis, but also how they should be improved. > > Scoped GFP_NOFAIL context is slightly easier from the semantic POV than > scoped GFP_NOWAIT as it doesn't add a potentially unexpected failure > mode. It is still tricky to deal with GFP_NOWAIT requests inside the > NOFAIL scope because that makes it a non failing busy wait for an > allocation if we need to insist on scope NOFAIL semantic. > > On the other hand we can define the behavior similar to what you > propose with RETRY_MAYFAIL resp. NORETRY. Existing NOWAIT users should > better handle allocation failures regardless of the external allocation > scope. > > Overriding that scoped NOFAIL semantic with RETRY_MAYFAIL or NORETRY > resembles the existing PF_MEMALLOC and GFP_NOMEMALLOC semantic and I do > not see an immediate problem with that. > > Having more NOFAIL allocations is not great but if you need to > emulate those by implementing the nofail semantic outside of the > allocator then it is better to have those retries inside the allocator > IMO. I see potential issues in scoping both the NOWAIT and NOFAIL - NOFAIL - I'm assuming Dave is adding __GFP_NOFAIL to xfs allocations or adjacent layers where he knows they must not fail for his transaction. But could the scope affect also something else underneath that could fail without the failure propagating in a way that it affects xfs? Maybe it's a high-order allocation with a low-order fallback that really should not be __GFP_NOFAIL? We would need to hope it has something like RETRY_MAYFAIL or NORETRY already. But maybe it just relies on >costly order being more likely to fail implicitly, and those costly orders should be kept excluded from the scoped NOFAIL? Maybe __GFP_NOWARN should also override the scoped nofail? - NOWAIT - as said already, we need to make sure we're not turning an allocation that relied on too-small-to-fail into a null pointer exception or BUG_ON(!page). It's probably not feasible to audit everything that can be called underneath when adding a new scoped NOWAIT. Static analysis probably won't be powerful enough as well. Kent suggested fault injection [1]. We have the framework for a system-wide one but I don't know if anyone is running it and how successful it is. But maybe we could have a special fault injection mode (CONFIG_ option or something) for the NOWAIT scoped allocations only. If everything works as expected, there are no crashes and the pattern Kent described in [1] has a fallback that's slower but still functional. If not, we get a report and known which place to fix, and the testing only focuses on the relevant parts. When a new scoped NOWAIT is added and bots/CIs running this fault injection config report no issues, we can be reasonably sure it's fine? [1] https://lore.kernel.org/all/zup5yilebkgkrypis4g6zkbft7pywqi57k5aztoio2ufi5ujsd@mfnqu4rarort/ >> [1] http://lkml.kernel.org/r/Zbu_yyChbCO6b2Lj@tiehlicka >> >> > 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. >