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 9B5A0C46CD2 for ; Tue, 9 Jan 2024 15:47:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2940B6B008A; Tue, 9 Jan 2024 10:47:44 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 21DC36B0095; Tue, 9 Jan 2024 10:47:44 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 071526B0098; Tue, 9 Jan 2024 10:47:44 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id E44406B008A for ; Tue, 9 Jan 2024 10:47:43 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id B6CD2A0902 for ; Tue, 9 Jan 2024 15:47:43 +0000 (UTC) X-FDA: 81660202806.29.5188409 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by imf26.hostedemail.com (Postfix) with ESMTP id 544C0140014 for ; Tue, 9 Jan 2024 15:47:40 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=yuCqZmQz; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=u9NJlJkP; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=yuCqZmQz; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=u9NJlJkP; spf=pass (imf26.hostedemail.com: domain of lhenriques@suse.de designates 195.135.223.131 as permitted sender) smtp.mailfrom=lhenriques@suse.de; dmarc=pass (policy=none) header.from=suse.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1704815260; 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=pLXaYBDIft5KFgQ9nA2lRfdPYbiij75xCMbxbUzR9gg=; b=VCKnKpRKkQdZNsPsJdjRvx+74NG3WqX+jf5j15oWFnfr4kzN+uafpN21R/4foLtcT4OMVV WYGmBNfTC/WHwoOIoZfkyUmBarsLayn4d4Q7MbPErcIAwYap3zIUEpCYPf7uPN974T1ff3 ezSqjOonBAqNp1i/yJsryNXzMfdInNk= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1704815260; a=rsa-sha256; cv=none; b=O7kr1YwVLBAR7azW3diDyZ/LaNOKw3sM0ogLjWZKrjg+pO/i0rpcm9oI+mIdtBPiQdZk+G km4NOFTf2gKIOkFbdj+OA/M+ZlpFzS47sZRG9WnWFQ2wFaEya8esld1u+GV7VsMjlME7B8 nxJiyyc0IR7Zqi/1Zgtze7u6xpDibUs= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=yuCqZmQz; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=u9NJlJkP; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=yuCqZmQz; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=u9NJlJkP; spf=pass (imf26.hostedemail.com: domain of lhenriques@suse.de designates 195.135.223.131 as permitted sender) smtp.mailfrom=lhenriques@suse.de; dmarc=pass (policy=none) header.from=suse.de Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 201881F813; Tue, 9 Jan 2024 15:47:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1704815258; h=from:from:reply-to: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; bh=pLXaYBDIft5KFgQ9nA2lRfdPYbiij75xCMbxbUzR9gg=; b=yuCqZmQzW1AAbNHxGs02nXFdpNObqdmT7cVUPlqGZWUY2Cjiadfxm2GwFhE5pUV0k2q9SN XxqN1xL0dzQCrxK7q8vAkKY39a7taea0SFd1iFJjtLq3PYYPchZvayNHmstm4eWqjc2zeU k3scUPV7z9DUCe9dn5HUACVOChF+A8s= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1704815258; h=from:from:reply-to: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; bh=pLXaYBDIft5KFgQ9nA2lRfdPYbiij75xCMbxbUzR9gg=; b=u9NJlJkPptNUeNQYK1ziJmCupDfn9OeuOVZWW9JWyDy66jNu/ayoh/itXoAY1xVygKBm2E 58Uk61P1oab9WTDA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1704815258; h=from:from:reply-to: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; bh=pLXaYBDIft5KFgQ9nA2lRfdPYbiij75xCMbxbUzR9gg=; b=yuCqZmQzW1AAbNHxGs02nXFdpNObqdmT7cVUPlqGZWUY2Cjiadfxm2GwFhE5pUV0k2q9SN XxqN1xL0dzQCrxK7q8vAkKY39a7taea0SFd1iFJjtLq3PYYPchZvayNHmstm4eWqjc2zeU k3scUPV7z9DUCe9dn5HUACVOChF+A8s= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1704815258; h=from:from:reply-to: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; bh=pLXaYBDIft5KFgQ9nA2lRfdPYbiij75xCMbxbUzR9gg=; b=u9NJlJkPptNUeNQYK1ziJmCupDfn9OeuOVZWW9JWyDy66jNu/ayoh/itXoAY1xVygKBm2E 58Uk61P1oab9WTDA== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 22D0713CB0; Tue, 9 Jan 2024 15:47:37 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id WtI6BJlqnWVnVQAAD6G6ig (envelope-from ); Tue, 09 Jan 2024 15:47:37 +0000 Received: from localhost (brahms.olymp [local]) by brahms.olymp (OpenSMTPD) with ESMTPA id d854d863; Tue, 9 Jan 2024 15:47:32 +0000 (UTC) From: Luis Henriques To: Johannes Thumshirn Cc: Jan Kara , Matthew Wilcox , "lsf-pc@lists.linux-foundation.org" , "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-fsdevel@vger.kernel.org" , "linux-btrfs@vger.kernel.org" Subject: Re: [Lsf-pc] [LSF/MM/BPF TOPIC] Removing GFP_NOFS In-Reply-To: <20f3de31-fbb0-4d8b-8f34-aa1beba9afc9@wdc.com> (Johannes Thumshirn's message of "Mon, 8 Jan 2024 11:47:11 +0000") References: <20240105105736.24jep6q6cd7vsnmz@quack3> <20f3de31-fbb0-4d8b-8f34-aa1beba9afc9@wdc.com> Date: Tue, 09 Jan 2024 15:47:32 +0000 Message-ID: <87cyua33vv.fsf@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 544C0140014 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: nnnzuczg999mgewhpctepomfps77jrwo X-HE-Tag: 1704815260-579859 X-HE-Meta: U2FsdGVkX18nNLTEdYzkbQv+TS2IonE+snxYHPpiHKd4PWD/Kp4uVQMIfaeSvM6Ecb1tPd+oFp+2shHAle7WbG3voOAlLzxP2trotgiiwJh0Og4S3ux5fRqsAygyZvCzibCQmhYQOZEMgMq/Om5OLxbWbzrGQXGlj3Bbrl8Rh1dAWK3LMIYuVAmGjPru9hRqcZz6MmXCv9sMg2S2H5mmMXAHi9yC1G7Orta0aFWAvGV7SflOXOn3noGjPhX4ilH0ARH2APpW8WTUQqSVKoLpJCnnbIwJaxpZczZPB074gusAqTQHKgj6nRxJH1vMTHimwVvknlKnwkPEV9NbF2aDpPghusIaPMPEI93j+t5/UbM4SsYfeO//w8gK/ty3kEaUQkHFPRp7uIgjxhciXbxc1YlV5eIgoY8gMOim1+Gp2W786HhE7aRRq8Soh4lzmPi5YhlX4RlPXtP/hAS9CtndbC5ilXVDoqL3cjuUby/d4xoRy0ObUB4UMyBdLQqlFlNF4S7oH2xxYCfTprGTYaWLp/UlT7NJ7iYuBtGSAKFUS6PqDV3HmLxuRb0aluzmtrsa0NpfqY/6BtIZ1snoXhJNa9E6JV+mq0GoQ9LAA4a/ybYHEUE4pHM8RJ9hnVnWQCsjUKnGXsYH4yuLmdZVOUoxWCtSlQTZVCm5jTcotxYj+yQOXrsWDnYSARrOWgikSQUSxEx01KpzeoUX2u4jTX5y+5mNHG0uagJfTbvFPVVL+a0OfKKeJuxEs6okXP0v0tpsnKwFvVFpSKhrBr/a4oE/4agdnDhaf5CxLt6dLXdtdTz8RBPMc2KllpaQGWiGfS8p3rOzK+3CdkmfCM5+VdEhEPXGlIG6O8FXPP1+ryP0ufuSYScY7WirNJrbtM+xnDKGmsgVxP0lZK81hGU4Hq1eK4PVY/RjCRi2VxymSQ1vrfbEVOn6mh2q1Qtr8kVYf8i7CupLEeVafsyquO2EOme U69sRF0D /wXc6o8SxyZql94JrkbX0vcr+UrKOaMoFyal6QTygxntHcg9q7GagCb1wd/LMY+UwFRujSygSt5BCyd5cosfCzyhbidZ0sKgRRXtbnKotSH7v3Hw2s/JGIAL7j/mvvd6R8OHJ3BIO+G9EN8ZmXqmQmUVDhllEQSukI2DjeuR8cCsnix0W05i7z2nztlWd4XvzECkuEXtqFYKTU4MoI6s9+qf7ML1YADwhK7Opax01s5JPv/rBK0JWKHB/QbkuFxg1wRt7MXnTB24psVG+T26Whv2dA7vxmxV65A14lWcHmaK/MhB/VtAo3mLPDmKI/RrTQArf9spzxKigyLejYJBkwy6XzMo4IJUcqS/tOXxshN84+U9rgNZ4pfbEU26PGR224cttDrZ5yyZYTGs= 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: Johannes Thumshirn writes: > On 05.01.24 11:57, Jan Kara wrote: >> Hello, >>=20 >> On Thu 04-01-24 21:17:16, 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. >>> >>> 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. >>> >>> 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 >>> 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 >> I agree this is a worthy goal and the scoped API helped us a lot in the >> ext4/jbd2 land. Still we have some legacy to deal with: >>=20 >> ~> git grep "NOFS" fs/jbd2/ | wc -l >> 15 >> ~> git grep "NOFS" fs/ext4/ | wc -l >> 71 >> > > For everyone following out there being curious: > 1 - affs > 1 - cachefiles > 1 - ecryptfs > 1 - fscache > 1 - notify > 1 - squashfs > 1 - vboxsf > 1 - zonefs > 2 - hfsplus > 2 - tracefs > 3 - 9p > 3 - ext2 > 3 - iomap > 5 - befs > 5 - exfat > 5 - fat > 5 - udf > 5 - ufs > 7 - erofs > 10 - fuse > 11 - smb > 14 - hpfs > 15 - jbd2 > 17 - crypto > 17 - jfs > 17 - quota > 17 - reiserfs > 18 - nfs > 18 - nilfs2 > 21 - ntfs > 30 - xfs > 37 - bcachefs > 46 - gfs2 > 47 - afs > 55 - dlm > 61 - f2fs > 63 - ceph > 66 - ext4 > 71 - ocfs2 > 74 - ntfs3 > 84 - ubifs > 199 - btrfs > > As I've already feared we (as in btrfs) are the worst here. It probably won't make you feel any better, but the value for ceph isn't correct as you're just taking into account the code in 'fs/ceph/'. If you also take 'net/ceph/', it brings it much closer to btrfs: 63 + 48 =3D 111 Cheers, --=20 Lu=C3=ADs