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 37B21C3DA6E for ; Fri, 5 Jan 2024 10:13:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B4FC06B02ED; Fri, 5 Jan 2024 05:13:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AFDFF6B02EE; Fri, 5 Jan 2024 05:13:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 99FDF6B02EF; Fri, 5 Jan 2024 05:13:21 -0500 (EST) 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 85BC36B02ED for ; Fri, 5 Jan 2024 05:13:21 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 55B2B160A5B for ; Fri, 5 Jan 2024 10:13:21 +0000 (UTC) X-FDA: 81644845002.18.2BDD737 Received: from mail-lj1-f176.google.com (mail-lj1-f176.google.com [209.85.208.176]) by imf27.hostedemail.com (Postfix) with ESMTP id 4432740004 for ; Fri, 5 Jan 2024 10:13:19 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=dubeyko-com.20230601.gappssmtp.com header.s=20230601 header.b=iZ+0TIxE; dmarc=none; spf=pass (imf27.hostedemail.com: domain of slava@dubeyko.com designates 209.85.208.176 as permitted sender) smtp.mailfrom=slava@dubeyko.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1704449599; 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=pb8qWmhccm9eam1IG6/mzCzwkOR/9EGblOaiwee7lpg=; b=IoanJFo750I9bODwIYNHm00tFi1eiZqmzK10tcr7Px9gb2qWC2jO98AR9vbrFvKNX9tsN9 hUXfFGVu0wDIfvBf6rSnfKuvaEILlmJpXdr7/N49c4vvPsk2kilIRFwr41v20wQzpNJ0CB NftEGS4m6UD0JHEI5afGS9o4ztZKSHs= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=dubeyko-com.20230601.gappssmtp.com header.s=20230601 header.b=iZ+0TIxE; dmarc=none; spf=pass (imf27.hostedemail.com: domain of slava@dubeyko.com designates 209.85.208.176 as permitted sender) smtp.mailfrom=slava@dubeyko.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1704449599; a=rsa-sha256; cv=none; b=UZLs7hgai1wjcduqw5nkr7NwwkKkPXDWxOqA4uS2PNUA4B5DQRrkYbXkNmvHAFzPUcyGTb bxWXJxX15Ek705kbBDIVvX/l3u/06ySMATwEFHO3vz8vN72pBX5aNk97z/f9xcERVP6Zy5 as1s87jkadlTyZWP+FBDGHOyjqJXPS4= Received: by mail-lj1-f176.google.com with SMTP id 38308e7fff4ca-2ccbded5aa4so16870191fa.1 for ; Fri, 05 Jan 2024 02:13:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dubeyko-com.20230601.gappssmtp.com; s=20230601; t=1704449597; x=1705054397; darn=kvack.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=pb8qWmhccm9eam1IG6/mzCzwkOR/9EGblOaiwee7lpg=; b=iZ+0TIxE+g32UMJL/bv4zXMG7gOTBMB5OOo/+yYttjAmMedQWRfX4g3/B4U4drNIWY swSmhJEMnb8npKqtppJtUxKUe/ZC00xKJGzoqCbWAKFNR9MN3aVnQlDmatBfbn3i5qUh WCpoDc7MyW82KNEgvCacHi6XxMxz1NiG6+HicxIWU0lwnY/nTHiygeQcF17mUlB/bPCT qyeHBKn+InukT1bytbf7KkySK3nukAYjzGJCm/IZHfZfAQNcqoX1l0isy7LWSj34jMPO KERMSSIchPimighMmkreFtPp0j3hBM7n/+qANqWCnv2pqdTXd2Al48uC+s/36sXwiKTx BJug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704449597; x=1705054397; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=pb8qWmhccm9eam1IG6/mzCzwkOR/9EGblOaiwee7lpg=; b=XZDDDvVKgTDQCYXat+j0hJriPcgJUukoTvHc0xFA2LnH46NAXlNfOasonU2/Gzl7xy iF0W/cjm4d+qVdBWlPk0wrp+bPNcsFaF5pL2h1ttuoWHOOt0f7q1eiDA7rC5RPowdhJ/ hGEIOv8ib8BGoRD+Bwxgqm/ZlmXqWARQANCZ2RK/nK+EPBC2WukMOFUNpmYuajyjHo0c DS4jGNpa0G3efV03/32fhiYOwcX3B6XIsvWifVa2GBe+o1jel3kmtsjkqOTb5ut0Yetk zEW4PQJNEN9110fHZMY/6IN6vzeGqdJZxBHUrLWVCcZl8SsxXMS4IHIFK30GVhW3KYHD 5udQ== X-Gm-Message-State: AOJu0YyfCeSWQEfP5rMFYpEirshl2T2KYGItz5ehdBujAeObE3i2EC5s xfNwqmI14OYgg9SakiaVyk20jrnZw2IYWw== X-Google-Smtp-Source: AGHT+IERFwtvcyoPP3L+QB9SFl8+7lNrV2k0KLfbM/7+3R7xK9hX+EDB4G+sBp41ebG01fKH0Phabg== X-Received: by 2002:a2e:be93:0:b0:2cd:1d5d:322e with SMTP id a19-20020a2ebe93000000b002cd1d5d322emr1306524ljr.10.1704449597179; Fri, 05 Jan 2024 02:13:17 -0800 (PST) Received: from smtpclient.apple ([2a00:1370:81a4:169c:3983:bdeb:5f19:e2e9]) by smtp.gmail.com with ESMTPSA id n23-20020a2e82d7000000b002ccb9f5ffcasm262090ljh.93.2024.01.05.02.13.16 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jan 2024 02:13:16 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.4\)) Subject: Re: [LSF/MM/BPF TOPIC] Removing GFP_NOFS From: Viacheslav Dubeyko In-Reply-To: Date: Fri, 5 Jan 2024 13:13:11 +0300 Cc: lsf-pc@lists.linux-foundation.org, Linux FS Devel , linux-mm@kvack.org, linux-block@vger.kernel.org, linux-ide@vger.kernel.org, linux-scsi@vger.kernel.org, linux-nvme@lists.infradead.org Content-Transfer-Encoding: quoted-printable Message-Id: <2EEB5F76-1D68-4B17-82B6-4A459D91E4BF@dubeyko.com> References: To: Matthew Wilcox X-Mailer: Apple Mail (2.3696.120.41.1.4) X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 4432740004 X-Stat-Signature: 6qku4d54ih8848yf68m1hdps1yxfnze9 X-Rspam-User: X-HE-Tag: 1704449599-230690 X-HE-Meta: U2FsdGVkX1+RIXTXf018XuiYvizmlWtH8m7HZ54ikI40DzbViBfeHc7pdwt5aTooggfbq+iGvQIS9LNNV0nPJFwe4Od2rkVRzmLSIYAFHv1ncm7TVZ8MzjNs7HzI6f9CakfSymFt6+BetyWuRcRc7Vir7CYlEqPSq2PtsXdKBKHKfW88Ab75NTty5V+vPh6YCYzFBYKHm1CqUmDbBuVCgcKrzuTIwJkh1yZnrPi0Df6htMWUJ/jPgUJyOsj2W36WT8Zm2nhixeJC9gk0cJOD/1qalX/vQqOkb+esMSBdOPtjshT2Ey6qYv0Jqdgccy8K8LIRb/VOBfWxkza18typpNMWOiX0bWAE2ne2yYnXwbA+/TqkuanXclrsccjd0PX62K8auQ5kcxNGxSCxeXxBuSXyvb6wyMm+qcws8BS/PEPoUw1nJtbOQnvKLP7zvHdPGnrqqrUS03amn5kYJHETaxpK8piUgL4Jcel8XG7cyMvCvxGbRk1Vh9IH1CVH+SJd788Ac3HA+g1/8lB/Y2G3GUcBPqjk/lxF0uFQututhwo3KuTtrz/W2r6EyfKMb/o+NajBUoSKv1QaxiLwPpb9kjfYgiezD0xuCyKugr5sT/2btY1Hk7opW9Y/W0Nyc4OMi/xnVFDnfAxKfj3OcxtDtSoru6FmtptwG/5Q7OCzSfml6wMs9d4OCU0QNIoxCkHKkk21rkqkF9GFYY0PJhnsFaApg6FzpH8C6beLw5//ELSCu3+Hvm7/IpQ7XXHX6iV544epclRhPV9FJOrkn3knBUeV2WHjEvqP6Da7OP7q47H7Yze/kvDyEw+5vfYulEGhXaJhfuAcVKeGhDBnhN8ALCKZ6ddy7pSYPGhpnxYXwWf8dRNW4ilWEDa+Uq0J6y78hGVste1ndNvDr0v5pOGpXBwTlG4eOGwftRqQ8x1LmptXILvBdoK+0tbPXi2CJYioCgkcKt4kIP3WmAQCcS+ dZceThae CfkHqNXJMZdA4MYL5S/GrhZl1jsURzaUSpObyoAUy6MXjH9nAkLV8ZoF2M2GO3OCPOv4wtcZIN18xcvTitMWPsirsrCVlMmP7m83ISn/RvKljqKenoR023OZJMzpnHLsNhoyZzORABI+REljhcTpKIGMsfTZ17ANQtmLEl4qbEb/0y2LUEq4s61s5JxYig9uh3SVY97SUSOrSQf4G8a5JW788Fq1ZmBUCxhZ9AgwctMUu8scYQ61x6NM9VBBUC6YHaWTHZIIDBXypaRckSrxopanczlgydLcFYvDTO+1bsHV7cTIDHxkEWEW4aUqYaePMFbKfuAdsGf592fzOvFuRS4x8+whIXLQ5CSRL3EzEcs1HGVgrXTJDakEUAYpkrWNVwhYi4lFyW8vG4U87PP8RHhQoQ3KpvCzHOQjIGKHRNQw+XQz4X23AOZmo0+GuQydT6t6dIUgkkjXrMBdaDDsOiZrJXQMqH3D16QyDzVGPM9YYW/R0b/hi6TLKU7Ri/qcemV8+Y0Y/ALJQaHszFGx6tDlx8hsXo4NMAsYHEh7MNnxTkPE72sNmZGtgFMrqiW7AxZh4TPoHBICiQVjSV+x6xaTnyieYghJf9NA2JvUxfTCdJ0N3DC1PFBDnQ0TW8mHUrchpndu844zRm57AuYKW01zs3w== 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 Jan 5, 2024, at 12:17 AM, Matthew Wilcox = wrote: >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > The memalloc_nofs APIs were introduced in May 2017, but we still have > 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. >=20 Many file systems are still heavily using GFP_NOFS for kmalloc and kmem_cache_alloc family methods even if memalloc_nofs_save() and memalloc_nofs_restore() pair is used too. But I can see that GFP_NOFS is used in radix_tree_preload(), bio_alloc(), posix_acl_clone(), sb_issue_zeroout, sb_issue_discard(), alloc_inode_sb(), = blkdev_issue_zeroout(), blkdev_issue_secure_erase(), blkdev_zone_mgmt(), etc. Would it be safe to switch on = memalloc_nofs_save()/memalloc_nofs_restore() for all possible cases? Any potential issues or downsides? Thanks, Slava.