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 D3E7FC47073 for ; Thu, 4 Jan 2024 21:17:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AB16E6B00E4; Thu, 4 Jan 2024 16:17:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A60ED6B00F4; Thu, 4 Jan 2024 16:17:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9298F6B00F5; Thu, 4 Jan 2024 16:17:33 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 744816B00E4 for ; Thu, 4 Jan 2024 16:17:33 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 42AD5A1998 for ; Thu, 4 Jan 2024 21:17:33 +0000 (UTC) X-FDA: 81642889986.20.477249E Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf17.hostedemail.com (Postfix) with ESMTP id 19ED840006 for ; Thu, 4 Jan 2024 21:17:30 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=ty799Qn8; spf=none (imf17.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1704403051; a=rsa-sha256; cv=none; b=Yof9kwv/Dl2fmQug7Bs8cw3JDeXuFhzs2OnCRTeXX0lkbGOqsgEFeUKBI1s1BigR0En0z4 RDRajSOVxZGHokPkC5efDslIhBIemsuIHFeTt8UUHqbs+mCwwF41900rQC0jVi/G+ukWsG RGDXVqzcs0knQR30reSjrvR2lcveViY= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=ty799Qn8; spf=none (imf17.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1704403051; 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: references:dkim-signature; bh=p5F8u3xrKU8ESZxmcg8jQ8IAjNp1yE/fjU1J5AXQvGQ=; b=5S2LAN3DMUhffNvvHkULjQ2oR4GCA0MIFXrQC7kqqNNLenNVGdbOrGDwNTLAw85skCeuwS Xm+n+qnrh0aIVCR1YLzilwE0YHeAODQj2IBS00+F8HNieUIp82lmwp7IHqiTueq+4rZa8C nCuFjGas1XP3t0oBcUqcItvIE4e7QIg= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=Content-Type:MIME-Version:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:In-Reply-To:References; bh=p5F8u3xrKU8ESZxmcg8jQ8IAjNp1yE/fjU1J5AXQvGQ=; b=ty799Qn8Fd+rytCk14M0ZVq25I YiBoR7XxLbFmlNS85l+O0gooTrHaDk5fhLePvNU0dGp4e1aMmTnss9STQyHl1VejW4/57v7YeIMBT ZP9rfvynFQ/IN6FqUpfPmxtyPBqFFxwyJMh/iOFqQYxJdTTEz1eSljsz03RUgd9NPFc9D695RfHwk +08zzTszFt8/e9TS1tjVeg0a9Dg7clSrdazeYNx0BSMUnh50XbIuN4hkn2wwogAacauBJO2ucG1rP JnlzoMgHsQUMwe3gYgnlXHjcmHCDNYpPswNwzduYNn/s2OLszGXp84YD0ABSGA9UbbP+tu1yvCFeQ WLAfi1sQ==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1rLV5Y-00G1t1-Vo; Thu, 04 Jan 2024 21:17:17 +0000 Date: Thu, 4 Jan 2024 21:17:16 +0000 From: Matthew Wilcox To: lsf-pc@lists.linux-foundation.org Cc: 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: [LSF/MM/BPF TOPIC] Removing GFP_NOFS Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 19ED840006 X-Stat-Signature: uymkwmxygspeafnxndfdfk83jktfp5sk X-Rspam-User: X-HE-Tag: 1704403050-903103 X-HE-Meta: U2FsdGVkX1/va6f9O89Q/f6Kyxq++r7n0GXIP/ZTa4ZfaBiYqiw8ZXPmRP9Z6VagXRoT9xQk26scP3e0cjPRKCCcjT3q372bvVmSRZ9Y6A6o0K9Tz+MEdDcpT1MPtgdg+GKPBFOKf/woy9KfeQCzryxwUPZ5qFyy/StSrnV9V9U1MwbO8jouki36V/vPZSl98HYe3+KiB5od83MVD9yGM1fbGLKIr/sdAGMig8Om2RfjrL01VSgdtd1ot5e4hGe7dzD8G0oTDv9/ggzFEgWKP0zkvwc8rLGP7uUOqDT4P94HKvbtTe63nbu7SHvuxzIx92RejtrFXweiKWdQo9xyMUOYJaSs9QNmq9rpg54Jh5tv0WxhVNh7pWPr/+kOiqufUbH8GNIVNMOE+xzDyLZNqSB+58a+jDEQwF7tWwlL0XD5eGoCQijlne+zKuzwkpVHcZ4hhEvnTrZTrnrSKZZ2SXQN0J9ifdZZub3/SrC5rom3x2rNO4R4BF+j53p+bkqIpciWygo5bAD+M6NmWZnkjt85dgHE0WBpsjhMK4FZNgpkLR+a2dS1Owhs6CjTfRudRtD5GKmPeeXb7wsv5SEI6y/HUShwQ0HKbzG4wrJJuxs+eR/SacBine9kb8t5S543TynbIvONpHyPBDecMQOkNnyeAdIz4LwNoopOBQiOwUSWuFZD1QSYlliOpS4z/iigUCysaAQUO6V6TM+hh1kujgN2y7qNHSw0HKSotFwZy//oqNhygKnw0VOYtxwLY15WcSji7QgLUtn6udxrTKWTdtqQUnyjRSqMLibtyueitoJgPeLqXHgESsV6zx+xKspEPQOF4a65hfL6O6VpUCcIu8oEC6AZXU+Zqffp9m1ed9Tbz6L3DdMPNM/2MHVKfVWgTDo3k2lZFZ7GbyNc2FReg7+rHALq1Kjitzk9pGDqKYtqDte7hcY1wN/x5fP6OfYNwXFFQUNKXYy8Yjhn+PR ImxdeJD3 wMYRFGMdEHLgpwSkUsxO32u/u+z71SEPvXtBfHMY30kHlYr4Qd2SazWb1VIksKIWvsHkG06jn0g3V6qVUyyTBXpipLdUR3tknJnIU8/gPxFXzlNjXX7RFf8qGtZ5aBSzSxDzx8arcp42xKiHAjQWV7D7MPyIlyaXrI/xNx92fz7WG3W4Do/EznEkQTg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000049, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: 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. My interest in this is that I'd like to get rid of the FGP_NOFS flag. 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. 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.