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 3B186C3DA6E for ; Fri, 5 Jan 2024 14:17:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AFD216B00E3; Fri, 5 Jan 2024 09:17:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A7C566B00E2; Fri, 5 Jan 2024 09:17:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 91EBD6B00E3; Fri, 5 Jan 2024 09:17:36 -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 7F4926B00DD for ; Fri, 5 Jan 2024 09:17:36 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 4CA631C1512 for ; Fri, 5 Jan 2024 14:17:36 +0000 (UTC) X-FDA: 81645460512.11.E4B24CF Received: from mail-lj1-f177.google.com (mail-lj1-f177.google.com [209.85.208.177]) by imf04.hostedemail.com (Postfix) with ESMTP id 6481940025 for ; Fri, 5 Jan 2024 14:17:33 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=dubeyko-com.20230601.gappssmtp.com header.s=20230601 header.b=pa2tg+bl; dmarc=none; spf=pass (imf04.hostedemail.com: domain of slava@dubeyko.com designates 209.85.208.177 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=1704464253; 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=QVWWEZC0nTAcEXYkvWfohoACi+DyynjzoGETkqq6WTk=; b=nJI1hjJ3yqjpTCGCEkF35M/P+V7M8puPfh0Qc0lzUNZP3orgnNW2yzfCRmWaLkbwzod8ag oxeYVyB6yX8LJ74n6AVKTN2I+hKHJfT5eQVDObZn2AWHpOtJQXYKqZejOkX41GzxaxuT3Q NDccQfmE+LXGB6/gCb74Pf3X+9ugF8o= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=dubeyko-com.20230601.gappssmtp.com header.s=20230601 header.b=pa2tg+bl; dmarc=none; spf=pass (imf04.hostedemail.com: domain of slava@dubeyko.com designates 209.85.208.177 as permitted sender) smtp.mailfrom=slava@dubeyko.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1704464253; a=rsa-sha256; cv=none; b=IjeXRs686FasqgqF1bX82OrHByb98mXYgwjz/F+QtKfrs+Nin8M3AIjlFyJL5GYRN2s79z 4Mx9/6YmEXOW2YMrgb+vVvQRZo1S1M7TOGJE7y+24g5celuFik1yqSMRuOmhPVnVpPKdPA n5r7NgA7ZVn0xbFBfYc4xf0e8n1M/hQ= Received: by mail-lj1-f177.google.com with SMTP id 38308e7fff4ca-2cd20d9d483so19407631fa.1 for ; Fri, 05 Jan 2024 06:17:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dubeyko-com.20230601.gappssmtp.com; s=20230601; t=1704464251; x=1705069051; 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=QVWWEZC0nTAcEXYkvWfohoACi+DyynjzoGETkqq6WTk=; b=pa2tg+blkUK+9+GMGN7iU2o5a8izt3kyzxL3Ivh4fN0+LDee2uGlTUe2bobncFNggk TQD7nRvaoa8MQV091P++ZmzsuCLDjsoRhTkkMg8KAzTlN+IuH9NFgWXNiwztqTajUhMh oxwDo0qzS70TyxO8oEKH+t1XYgpbii1QRX4oTcMWhUcjnp4UCEA8hz3KcweKsPxGpa6O pDFagRMc3nmBGFLkROiWmSmWS4sLKcyyiu5d6blSsKHKNQJjRBU0uYL0OQwPTHMZXCyS 8yVLevj3ppsOt2+fyRoY84vu3hQCtJrIAeHdwJ+80cCY2tXLzfLGMdA36xW/ud7R4cxT 6bVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704464251; x=1705069051; 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=QVWWEZC0nTAcEXYkvWfohoACi+DyynjzoGETkqq6WTk=; b=jxbflNOicEojdr7Q/p+6lQwnCasoTUShdXDBPmWMhGDKfZtakv53vVKs/acAeMe70E fh1sOGxAhgC8L5nN5hz7H7dk3OM1c0ulMBJ5kGYfRqwCwqe+OYP7h20XXYkjuvvH4FIT OMTp2zbrQuqprseOYvCATwRNbiIbO5TglCVWFWFjExtPbbyV+Ovdnw/3iVF/wZTcmNvX tAz/ViJLGZVCypyPhPRoZkNjgVJ0LxdKYjhoDi2f/rmz/IjFNo6Cfsw2KtHYdq+3fDBH zQUhMf1TdIVs0nahg0frXfdRHfU7TblOlCwUM7sgT2MK4i1LkPT0KA/kqWQHw6i1SJZb +EHQ== X-Gm-Message-State: AOJu0YwJhkKWmU0lKSI37N13TrxwLJuxgWHuoS7FXqSxsxqs2Z34dkiw 2dlWWSOtXqXodLb12/RAbGF00Xg2Ct2/Tw== X-Google-Smtp-Source: AGHT+IFUzqFY0DMUD4VxQFC0jdTQ+04LaFR5XJF6GZDdXO/19l3HLlkR+Dh2SihaaVqGfq3vwivRNQ== X-Received: by 2002:a05:651c:2213:b0:2cc:8bd4:b860 with SMTP id y19-20020a05651c221300b002cc8bd4b860mr1337702ljq.85.1704464251368; Fri, 05 Jan 2024 06:17:31 -0800 (PST) Received: from smtpclient.apple ([2a00:1370:81a4:169c:3983:bdeb:5f19:e2e9]) by smtp.gmail.com with ESMTPSA id p8-20020a2ea4c8000000b002cca51c54c0sm337155ljm.130.2024.01.05.06.17.30 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jan 2024 06:17:30 -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-pc] [LSF/MM/BPF TOPIC] Removing GFP_NOFS From: Viacheslav Dubeyko In-Reply-To: <20240105102657.fwy7uxudqdoyogd5@quack3> Date: Fri, 5 Jan 2024 17:17:25 +0300 Cc: Matthew Wilcox , linux-scsi@vger.kernel.org, linux-ide@vger.kernel.org, linux-nvme@lists.infradead.org, linux-block@vger.kernel.org, linux-mm@kvack.org, Linux FS Devel , lsf-pc@lists.linux-foundation.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <2EEB5F76-1D68-4B17-82B6-4A459D91E4BF@dubeyko.com> <20240105102657.fwy7uxudqdoyogd5@quack3> To: Jan Kara X-Mailer: Apple Mail (2.3696.120.41.1.4) X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 6481940025 X-Stat-Signature: etmms3866fy6wxakguxzi3onxsjuhkp3 X-HE-Tag: 1704464253-259648 X-HE-Meta: U2FsdGVkX1/rlHvHFtnBPX5+680bIM84hEanf0dP31KODCgrS9dqC0qADIaE1u4ZRgWW1A9yYoL20ufRu++hdULex/iihs1gm8ZgawCyo7K/bW9vm6SfU2iNGSfANKS0BLf5EJSPV6pegqTEK3UbiLnK/IqHSwpWb+EA8vtfDlJq78cWCkBk5Nff2VybQBOMH0K6nMEle3Rvd5WrB3GZvcQr51TbvQwIbIVonAVms3bIrwFHouFciek65L8MwfkxSx4RTrCeSKR40+v17Ln+jcI6o8MbeIn1mA8JBUvB2RwSbq3oFu5a/z/H2QgagBLAkF/y+HaY3MjaAXdps1ZTIifqaR0XJvJX2b3s3liQbFbCn/9lLt+7PdpH1t5FS8y9ornLS3F/hHoALXsOQcJY2D+Lna4SsHxeCk3o+K9ih/vE4baEd9WQGw8Ua7FWgAOp8FVCuu8CIZqNZ4n/6TIk7UjNNlyOULptz2C/L0WzI2UoTrQyIHimSknkI92MG+9XBr/4ABYOZZP9BNqGFXjlRzMZSDq+DjippD8KyqtSoFBA/6ni4HvJr6SABMkaW2T84l+K1ppcNK6jBcZwHmZ4VotPazmyULZieT0fBamDcUGPx2SxXKQWOOTwY+ls5flWDaOU5emQk63AbIRhXUtHcWGWB3V2wbNvPpLRsVY09aemlByf2LCn79OKDjDX2cywY+VQbizoP+sIWsDKFtaDBlkjVUoj0QBiPo5fBLDCnXjXzVvYLLLQYo6qt9GVP6Gsi/HxYeP3KThLV4W8NbYtObjCzw684+F4Dxggw25vmwQ+VJ0GFXe8mciojJfC+fWsBhNGOuHw6M1OpjXba6BEH9DVmKwR5HXqxIrtHqE/59OA3oDA9RLUU88oBTLquOSLWVFJEg7DL2t+I4hf/z/N8xV3+ft/RHd7xIYr2UNxyD4+3Eh4OknSqfDCzKQ896jRqL5Ti9TnoIG1Ks1ed3m I+dmZf6l sQ9I7IuHfqPVzkoOeRGTdnS0XfsuQ82N8KsEuhUxeSrvQsKtADthYLYb6nJI70kMP1V9JUuWQ+43r5udCrHNOwzvpU0591JqCjQP57Rp1Uf/A/Dsn50S0i17+W8+x5ceGqb8AY92cwAqLR3cBvyqTr3vwRH9FrfwDWIZ6FV/0TF9BfX/25e1F3aTG3BbCZf6RlQ5E 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 1:26 PM, Jan Kara wrote: >=20 > On Fri 05-01-24 13:13:11, Viacheslav Dubeyko wrote: >>=20 >>=20 >>> 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 >>=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. >=20 > Given the nature of the scoped API, the transition has to start in the > leaves (i.e. filesystems itself) and only once all users of say > radix_tree_preload() are converted to the scoped API, we can remove = the > GFP_NOFS use from radix_tree_preload() itself. So Matthew is right = that we > need to start in the filesystems. Makes sense to me. So, we need to summarize which file system uses the GFP_NOFS for which methods. Then, I assume, it will be possible to split the whole modification for particular phases of getting rid of GFP_NOFS in particular case (particular method). It looks like that we need to declare the whole modification plan and something like a schedule for such change. Would it work in such way? :) Thanks, Slava.=20