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 3D605C3DA6E for ; Mon, 8 Jan 2024 06:39:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 576116B006E; Mon, 8 Jan 2024 01:39:54 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 525976B0071; Mon, 8 Jan 2024 01:39:54 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3ECF26B0072; Mon, 8 Jan 2024 01:39:54 -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 2EBCB6B006E for ; Mon, 8 Jan 2024 01:39:54 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 80F70C071C for ; Mon, 8 Jan 2024 06:39:53 +0000 (UTC) X-FDA: 81655193466.06.C863526 Received: from mail-pl1-f180.google.com (mail-pl1-f180.google.com [209.85.214.180]) by imf06.hostedemail.com (Postfix) with ESMTP id 93690180016 for ; Mon, 8 Jan 2024 06:39:51 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=bDKfKeGk; dmarc=pass (policy=quarantine) header.from=fromorbit.com; spf=pass (imf06.hostedemail.com: domain of david@fromorbit.com designates 209.85.214.180 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=1704695991; 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=P2z/LFrpUod4EQohAwYfd01URT3cRlVCm2VHTnvRW44=; b=kmx/rarPkG3z92c/AnrCSghXqMPwib/gYBeU5tSeOBXQi2RkWDhOZgiU5y8Qhjlg4r1MKD bUSBt3qun+DhA7urCd0Z1FX4SZPZFgR92IKuKUjhr5nJM9LanG0P773JD8Z0/Fr/IgQLWV ZDUsHyvTODNHhvQw+dCFZYIutFOMgS8= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=bDKfKeGk; dmarc=pass (policy=quarantine) header.from=fromorbit.com; spf=pass (imf06.hostedemail.com: domain of david@fromorbit.com designates 209.85.214.180 as permitted sender) smtp.mailfrom=david@fromorbit.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1704695991; a=rsa-sha256; cv=none; b=O1yLQlnMJgbHyX2dH/wxI9jDhkQkMsF/nbvkR6ax76+Cg/ODibCdfTvnSQ4YA6zSSQdUc2 bggQTxrP89aR16l2iBTl1EiUp3roWzRReeTf4Tp56qJVxvpRdJgbNMAz9025rkvTftMAf2 UjfHuGEmcxvZWbF6P/VwDUEMNtP6c7U= Received: by mail-pl1-f180.google.com with SMTP id d9443c01a7336-1d41bb4da91so2320875ad.0 for ; Sun, 07 Jan 2024 22:39:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20230601.gappssmtp.com; s=20230601; t=1704695990; x=1705300790; 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=P2z/LFrpUod4EQohAwYfd01URT3cRlVCm2VHTnvRW44=; b=bDKfKeGkJ9xO5GNevheOGmAO7IPL1N55WkfyRGDKDuRU9TWd+4lDEXWGaVcSsr/GiY pB63B1/BSV5LDcGBACqacaR4peliX4ePst1pdKpM2WI1/iG3ofwt5xqn1X7Spe+/5HGP cF8oPmwVq/r2u6CcDsmdDM9AdbqI4VqcjcMcJ0v56brVUIA6ntJmX3+bbIhpRgK7M/Hg mJKZCz6W+PYp0dTmgFITa2MONbR1EHncnz72pfxre70f2ZahpqttxH/bjUjSkIaUFjWH 3MDCEf6OhHIenTWYZs6rsU7VrCl30GdgosAz8jmC26z6g6R+KTkJdxyGI/FJGJQmU9PV x0aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704695990; x=1705300790; 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=P2z/LFrpUod4EQohAwYfd01URT3cRlVCm2VHTnvRW44=; b=pxnSrZRfPQhcMPV+z9BX2Bzg7kgMHOb+eepmjkFMRfAPzgPmfFbBt/Gul7YmPI1Fvz c78JMKMagfnNCbthTuAy+Yw8Q6Prk06YRupLf5LRq4eeviPiLvtcb2QF2HEQoJ+V7VvB hbAmO7YaurEXlsDLJpoP7sm6xnL5JNpnOSg7g4OEGkeblT7pW3T4CafI6Dg5yhmCBsuC MAwFvVCZcH3uHj2Ly+pwIm6HqXpgWeBlOVMlGhuMtNc3P2YxHXEu0x86HpSvvWFQFVA3 Ag5ZVbu0y8SzrEsynBOpdK2ACzk1dEv7ZUpxorQ1Uiq7YxFPVxrVkEJrP3E3aPgzTFxf Zsvw== X-Gm-Message-State: AOJu0YyFzYYuSom9x7U5td4QNz+/RZ39HNIKR5Czl2a67JqcBJ2jB6ds Qw5hBNZ7MKUOLui+OdUoqbV/2XKMH77lWg== X-Google-Smtp-Source: AGHT+IEd5DltWMH/+FqCfCYBhgKXl9nxlvdK57zqowQUpnyKj7XaJTN1HbiuX5Fx9BCEtBJDAymiig== X-Received: by 2002:a17:902:be13:b0:1d4:3d04:cdd with SMTP id r19-20020a170902be1300b001d43d040cddmr791720pls.32.1704695990264; Sun, 07 Jan 2024 22:39:50 -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 j5-20020a170902da8500b001d4e05828a9sm5421115plx.260.2024.01.07.22.39.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 07 Jan 2024 22:39:49 -0800 (PST) Received: from dave by dread.disaster.area with local (Exim 4.96) (envelope-from ) id 1rMjIY-007WiN-2y; Mon, 08 Jan 2024 17:39:46 +1100 Date: Mon, 8 Jan 2024 17:39:46 +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: 93690180016 X-Stat-Signature: 6hjpobs4ww9a4drhoef37skrx1zmejop X-Rspam-User: X-HE-Tag: 1704695991-604294 X-HE-Meta: U2FsdGVkX18auNjRCl8ZmXEJKz0Ve4xW3QCPQ+Q5sOAotobaOEm3R4kIEf6Z4BwAw+fetSjLMv27ZCuy6dy3TCupwmsPrE15E13pUs7adXsSmngLxmE50Mt6W3M5HbFLAn9t8GWfw9b2vJlKMlgTF1dF/iKxDcjBPcAUmGC93H6X887RsaYJHs5KqN+9jUuM9Y6RlgZXAeeWQ+pQvoXyeApOmKyqn3Xef4JTgBGexJO+REKQPmsYNnI4IFi8AcoPm4IIdy5GsLe/suFKBxQ1Z3eEnVcKjck03FI3q5wqPp4U/edqzV2b5i1E2NAqApmXNENCh34sm7++8ruDp4zx+JpjM4X66Vfy1dzSyOqhL43ftCYRZQ+yeVrHv13kETvDKuH190qoY/Lgie398g+MGbcS8w3Vnpz+BNCYTcBQO4gWCrx3xx4mKio38O2CkIawMt2hqYz6FrlRwC1p3I4pAvERgUx11dZc2XYmBcDGmsMRt9uzXjPLfAiog+3M69oGCb1R0uZ8F6oWSekBDNte0bhOk77YMbWcQsFyyuTNTekbGY2zoruZ16JiQMzeq04LE3etd+KUXv63yWdP2vU4lkfj2VErEJurB5HaHuI9MhJbLIdsM4kfNnVbgw5jOf0s/ArOfp++ZLLzTAoC7/NT9t+qld5GTQbAoB9Gos6zVvJSsxMegN4Rdna8WF7oXY7JiroXCFzfJ/vCj+n75ghPiEE8LZ8UA7A9SB4EiXWZ3VZBbfKvnasif7EEt0BTkhnwrUEe8/fhHM3MjgAqSASJthc1u21+7uw0wjaWpovny4CEpllpSpeSf0xMaoXO6DLOtt7WjFXYPyLu5yYTXJrT1iAppKPJgVf/4yMK7e69ZMb0UA/lqBPUdAn3nNtkkzaydIbJtDaKCobVZj07OIFZtoGR8yWmFpDBlK2E1LhIm416Jyy9LVQCRpAMKUyyCx1lazt4Qzzbw4SA1/9GpxA yac0fQe6 yDiAq+auasS1tUYJaSbvEnDP6nQTvlEbtmnG5aiRGbKLZjc156B/9ULGIx5+wwMxgs9Pxkoj1YL58I2+Uqh568FO3j4VrYWJOW1bNN3xy5AN80y/u1hbSrtA+5VUrwB5NrN9Bg6GjHte94/U6ezixMCH8p8IUp70eUHAQQzDJGsiLEhtB8UypphJB+9lhXAfjEKBz3aQyGj9oqFDL2k4roOJAupTmp42oQHKgL0OsKp7P/xi5aj+9dmbqsmcy2caehJ66cniJvR8b76oT3XM1kJlpknMxhFPlJ6d7sGi6dAxRgjskCJdziAYj/gLUXu2pLdNRcxlSkktVFAhwSS7kPOTRnL+H79ybs69wdw1HHmExp8EtJs3G+OAPAYiHzj/kOhIFiUew0ETlATQmhWaZTecUO9Ayzk07nSysEXgme+K+BZ5035umpDIi/LgGaVHiPP3pLVTYHPpeltfOOfnFJtYpvH6BhzToln6C9u6zMgiqUO3u7VajNIE4whAUz1Ug1Ubtu3g4ApAQQlnEcdnriWgB/fuTh57IRQCllsUrbNBIIP8= 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. There are many uses in XFS where GFP_NOFS has been used because __GFP_NOLOCKDEP did not exist. A large number of the remaining GFP_NOFS and KM_NOFS uses in XFS fall under this category. As a first step, I have a patchset that gets rid of KM_NOFS and replaces it with either GFP_NOFS or __GFP_NOLOCKDEP: $ git grep "GFP_NOFS\|KM_NOFS" fs/xfs |wc -l 64 $ git checkout guilt/xfs-kmem-cleanup Switched to branch 'guilt/xfs-kmem-cleanup' $ git grep "GFP_NOFS\|KM_NOFS" fs/xfs |wc -l 21 Some of these are in newly merged code that I haven't updated the patch set to handle yet, others are in kthread/kworker contexts that don't inherit any allocation context information. There isn't any big issues remaining to be fixed in XFS, though. > 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. Note that this is the only way to use vmalloc() safely with GFP_NOFS context... > This results in better code within your filesystem as you don't need to > pass around gfp flags as much, and can lead to better performance from > the memory allocators as GFP_NOFS will not be used unnecessarily. > > The memalloc_nofs APIs were introduced in May 2017, but we still have For everyone else who doesn't know the history of this, the scoped GFP_NOFS allocation code has been around for a lot longer than this current API. PF_FSTRANS was added in early 2002 so we didn't have to hack magic flags into current->journal_info to defermine if we were in a transaction, and then this was added: commit 957568938d4030414d71c583bc261fe3558d2c17 Author: Steve Lord Date: Thu Jan 31 11:17:26 2002 +0000 Use PF_FSTRANS to detect being in a transaction diff --git a/fs/xfs/linux-2.6/xfs_super.c b/fs/xfs/linux-2.6/xfs_super.c index 08a17984..282b724f 100644 --- a/fs/xfs/linux-2.6/xfs_super.c +++ b/fs/xfs/linux-2.6/xfs_super.c @@ -396,16 +396,11 @@ linvfs_release_buftarg( static kmem_cache_t * linvfs_inode_cachep; -#define XFS_TRANS_MAGIC 0x5452414E - static __inline__ unsigned int gfp_mask(void) { /* If we're not in a transaction, FS activity is ok */ - if (!current->journal_info) return GFP_KERNEL; - /* could be set from some other filesystem */ - if ((int)current->journal_info != XFS_TRANS_MAGIC) - return GFP_KERNEL; - return GFP_NOFS; + if (current->flags & PF_FSTRANS) return GFP_NOFS; + return GFP_KERNEL; } > over 1000 uses of GFP_NOFS in fs/ today (and 200 outside fs/, which is > really sad). This session is for filesystem developers to talk about > what they need to do to fix up their own filesystem, or share stories > about how they made their filesystem better by adopting the new APIs. > > My interest in this is that I'd like to get rid of the FGP_NOFS flag. Isn't that flag redundant? i.e. we already have mapping_gfp_mask() to indicate what gfp mask should be used with the mapping operations, and at least the iomap code uses that. Many filesystems call mapping_set_gfp_mask(GFP_NOFS) already, XFS is the special one that does: mapping_set_gfp_mask(inode->i_mapping, (gfp_mask & ~(__GFP_FS))); so it doesn't actually use GFP_NOFS there. Given that we already have a generic way of telling mapping operations the scoped allocation context they should run under, perhaps we could turn this into scoped context calls somewhere in the generic IO/mapping operation paths? e.g. call_read_iter()/call_write_iter() > It'd also be good to get rid of the __GFP_FS flag since there's always > demand for more GFP flags. I have a git branch with some work in this > area, so there's a certain amount of conference-driven development going > on here too. Worry about that when everything is using scoped contexted. Then nobody will be using GFP_NOFS or __GFP_FS externally, and the allocator can then reclaim the flag. > We could mutatis mutandi for GFP_NOIO, memalloc_noio_save/restore, > __GFP_IO, etc, so maybe the block people are also interested. I haven't > looked into that in any detail though. I guess we'll see what interest > this topic gains. That seems a whole lot simpler - just set the GFP_NOIO scope at entry to the block layer and that should cover a large percentage of the GFP_NOIO allocations... Cheers, Dave. -- Dave Chinner david@fromorbit.com