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 BCC09C47DDB for ; Thu, 1 Feb 2024 11:03:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 58E286B0071; Thu, 1 Feb 2024 06:03:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 518436B0072; Thu, 1 Feb 2024 06:03:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3B7C26B0074; Thu, 1 Feb 2024 06:03:37 -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 2A7C06B0071 for ; Thu, 1 Feb 2024 06:03:37 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id A2B4740D7B for ; Thu, 1 Feb 2024 11:03:36 +0000 (UTC) X-FDA: 81742949232.20.317CAA9 Received: from out-174.mta1.migadu.com (out-174.mta1.migadu.com [95.215.58.174]) by imf06.hostedemail.com (Postfix) with ESMTP id D2ECB180012 for ; Thu, 1 Feb 2024 11:03:33 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=p+jScNvU; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf06.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.174 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706785414; 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=RlSz8ZIrAwCoFSqw/tUULV0T3HqV2hzVk61isq+820o=; b=3QFTGpLwsju/uasgbpCFOoE+teDG3iTByk5olWKcaGkZGuAC8zx/QphnzqilpRimzY4hl9 orsVRAzVKIgsLtcxfpe+O+YPwjuGyszrLGnS4vuaSe6Vjo67y580VujYSwAxUzYr3qC3lX QlsD+c0c8TZXvC43BcolbPKZgsAY14w= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=p+jScNvU; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf06.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.174 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706785414; a=rsa-sha256; cv=none; b=N/GdHk3/OQ8kTg3adSJgMZw2K5IyQHvLSzNx2uO6XGGkKc4Iy0ZMt4ETWsfgqCypKqgV9E 8jVgK19Wuyb/71hdVi4JUt0gN2rCOnn1/LAtwNLXTU7eD5K1x1Y1USN+Ivn2TmBFqS6fbj W58GAq1533adeCGBFQfUpzTU8hsJrkg= Date: Thu, 1 Feb 2024 06:03:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1706785411; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=RlSz8ZIrAwCoFSqw/tUULV0T3HqV2hzVk61isq+820o=; b=p+jScNvUWBCTFdCkjbGwgTkW/6OViNZk4zUKR3mGF60EZvPpu51MofwB8ReEtRYGZCcNyI UkVPonxXtkYctTYeOBMMvo5ipaBLRzjyk+Wcy3Hd7MF7T2vXWXnyUKTSrshzRmaOkXoxUI 35ThBS1N00e77qvNfPyeehgTCoOhq90= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Michal Hocko Cc: linux-mm@kvack.org, Vlastimil Babka , Matthew Wilcox , "Darrick J . Wong" Subject: Re: [PATCH 2/2] mm: introduce PF_MEMALLOC_NOWARN Message-ID: <3lzd24v653hn7ks6ocdeos6xkppk5l7pgun7nysmmmsfgrjob3@mqynwkythb4d> References: <20240126220756.395187-1-kent.overstreet@linux.dev> <20240126220756.395187-2-kent.overstreet@linux.dev> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: D2ECB180012 X-Stat-Signature: 9djkoeomaad7s6kpqpzk3agznzwa61fd X-Rspam-User: X-HE-Tag: 1706785413-960551 X-HE-Meta: U2FsdGVkX1+hv2PFT4DonR05yuLli2FBC4ZSeJHz10yIvjAZ6ETvQAdQaYakUBR1DnIH4jMcfk/7qkZ4ru1rlJi2PO6+gdytKaUPCYycQcHJ0W0vxzkziStoV2tHbNGGY6oITogKRsdNARk3yZ9n6EubyHPxeJ9pTd4lVqWwoq0BVBuwi6fDjMq0Gr+wL6UHTB7fLHR3bnpxQ0vHuCXV+A1e4RrrXaWyG51o8Fj+BkVs7tdv2UVw+ktObaaARL2SYr/t3GfL8xsIUoMnFduTzXTVApFrIpsH4BqCidG9fOJx3pEBvVGZvYq50ae6ogS8q4ol0sv3mXL1nde74FIIbK1TdqZl9pYYPnTm+40WWEjSkdcO/LRkrEo9TLGASqYJIGwzpdv0gGU5GbQeGlFo36oamNrNgFYRQC5o3xc8rGgyjEAZpuAmjbYyliWTsocvfvRUmb4B51U39jl8l/NKgg1wEOfFMYPbghYBnnyEBpczPC2vR0In0vZR3DKmqHgOqT6y8mfXeYNIjXmRbVswlxWlAu7lQLLzO9dtpHDlW7WKwLyqUVEQd3/wbeWH+l7/zQscAJAuaBYCfI1VgxTIlF0uTrZU8jkTEH7j5avdxBcXoModjl+LthRsIZ6xAtTk8ZzdNSgbvBy88DzEADiX0jTR4Tih6bip7tvImGCuWmPL/RDMmT1EuTjkYAjKugKBIXmc4x/K1lHD/s4NKGhaGmIHv3CzMF1sUwLJGj5y5Ky3XkiLXGQbqAACORFYHcav+rnSxbse4AMH0e+kuGnkzhW56h88fMoYSj5ftQW1uW55k8cT28vt1JhVUnRQEUO4HnZadr0+f7azFcTN0fb1jsZU4Znp+5wJehK2Xmfo3wYPKnYvT3vNJFttKMEANfKQdA3s5GW6LkSwFJUi752czPRgtJJ3gWdTy/Fp9g0R97Rd49lAKuJCid3ONCrr4ADtqnecfY1zmmATryRVF9l UXNhncV0 vmf9f06lrxI0G1u9MJaB4ew3R20C5Xjm9KmFtpNCTiGECLP4ois1WuoGJ+tVA70mE5Lu1C/qcWsz3ZXr9pBTuB3Ts+zprdlZqPvE27AM4Rxn9jbjL+oPvrtUsXN4XGZtLWZkYeDsrZd0j8cnSkshE4H7IsZeyGXHRU+LiQfjZ0ypizpZCZrHT+24eYmX/ahVjhS8eTgKxujuCa+/cpswHOvnMXvo/32tk5dqfpknpXyThBAoNgwdLsWt+G+9sCiCEzRV1 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 Mon, Jan 29, 2024 at 11:48:00AM +0100, Michal Hocko wrote: > On Sun 28-01-24 14:43:16, Kent Overstreet wrote: > > On Sun, Jan 28, 2024 at 04:45:32PM +0100, Michal Hocko wrote: > > > On Fri 26-01-24 17:07:56, Kent Overstreet wrote: > > > > If we're using PF_MEMALLOC, we might have a fallback and might not to > > > > warn about a failing allocation - thus we need a PF_* equivalent of > > > > __GFP_NOWARN. > > > > > > Could you be more specific about the user? Is this an allocation from > > > the reclaim path or an explicit PF_MEMALLOC one? It would be also really > > > helpful to explain why GFP_NOWARN cannot be used directly. > > > > Explicit PF_MEMALLOC. > > > > It's for a call to alloc_inode(), which doesn't take gfp flags, and > > plumbing it would require modifying a s_ops callback and would touch > > every filesystem - > > OK, I see. This should be part of the changelog. > > > but we want to get away from gfp flags anyways :) > > > > More specifically, the code where I'm using it is doing a "try > > GFP_NOWAIT first; if that fails drop locks and do GFP_KERNEL" dance; > > it's part of a cleanup for some weird lifetime stuff related to > > fs/inode.c. > > > > #define memalloc_flags_do(_flags, _do) \ > > ({ \ > > unsigned _saved_flags = memalloc_flags_save(_flags); \ > > typeof(_do) _ret = _do; \ > > memalloc_noreclaim_restore(_saved_flags); \ > > _ret; \ > > }) > > > > /* > > * Allocate a new inode, dropping/retaking btree locks if necessary: > > */ > > static struct bch_inode_info *bch2_new_inode(struct btree_trans *trans) > > { > > struct bch_fs *c = trans->c; > > > > struct bch_inode_info *inode = > > memalloc_flags_do(PF_MEMALLOC|PF_MEMALLOC_NOWARN, to_bch_ei(new_inode(c->vfs_sb))); > > Is this what you meant by GFP_NOWAIT allocation? You would be right > about this allocation not entering the direct reclaim but do you realize > this is not an ordinary NOWAIT request beause PF_MEMALLOC will allow to > dip into memory reserves without any limits? (Unless the specific > allocation down the road is explicitly GFP_NOMEMALLOC) > A failure here means that the system is really in a desparate state with all > the memory reserves gone which migt break reclaimers who rely on those > reserves. > > Are you sure it is a good idea? Unless I am missing something you are > just giving an ordinary user access to those reserves by creating inodes > without any bounds. Did not realize that; thank you. How about this version? >From 0e87e55058ccddde4b6bcc092f43e66a4e632575 Mon Sep 17 00:00:00 2001 From: Kent Overstreet Date: Thu, 25 Jan 2024 19:00:24 -0500 Subject: [PATCH] mm: introduce PF_MEMALLOC_NORECLAIM, PF_MEMALLOC_NOWARN Introduce PF_MEMALLOC_* equivalents of some GFP_ flags: PF_MEMALLOC_NORECLAIM -> GFP_NOWAIT PF_MEMALLOC_NOWARN -> __GFP_NOWARN Cc: Vlastimil Babka Cc: Matthew Wilcox Cc: Michal Hocko Cc: Darrick J. Wong Signed-off-by: Kent Overstreet diff --git a/include/linux/sched.h b/include/linux/sched.h index cdb8ea53c365..36de7a2343c3 100644 --- a/include/linux/sched.h +++ b/include/linux/sched.h @@ -1632,12 +1632,12 @@ extern struct pid *cad_pid; #define PF_KSWAPD 0x00020000 /* I am kswapd */ #define PF_MEMALLOC_NOFS 0x00040000 /* All allocation requests will inherit GFP_NOFS */ #define PF_MEMALLOC_NOIO 0x00080000 /* All allocation requests will inherit GFP_NOIO */ -#define PF_LOCAL_THROTTLE 0x00100000 /* Throttle writes only against the bdi I write to, +#define PF_MEMALLOC_NORECLAIM 0x00100000 /* All allocation requests will inherit __GFP_NOWARN */ +#define PF_MEMALLOC_NOWARN 0x00200000 /* All allocation requests will inherit __GFP_NOWARN */ +#define PF_LOCAL_THROTTLE 0x00400000 /* Throttle writes only against the bdi I write to, * I am cleaning dirty pages from some other bdi. */ -#define PF_KTHREAD 0x00200000 /* I am a kernel thread */ -#define PF_RANDOMIZE 0x00400000 /* Randomize virtual address space */ -#define PF__HOLE__00800000 0x00800000 -#define PF__HOLE__01000000 0x01000000 +#define PF_KTHREAD 0x00800000 /* I am a kernel thread */ +#define PF_RANDOMIZE 0x01000000 /* Randomize virtual address space */ #define PF__HOLE__02000000 0x02000000 #define PF_NO_SETAFFINITY 0x04000000 /* Userland is not allowed to meddle with cpus_mask */ #define PF_MCE_EARLY 0x08000000 /* Early kill for mce process policy */ diff --git a/include/linux/sched/mm.h b/include/linux/sched/mm.h index f00d7ecc2adf..c29059a76052 100644 --- a/include/linux/sched/mm.h +++ b/include/linux/sched/mm.h @@ -236,16 +236,25 @@ static inline gfp_t current_gfp_context(gfp_t flags) { unsigned int pflags = READ_ONCE(current->flags); - if (unlikely(pflags & (PF_MEMALLOC_NOIO | PF_MEMALLOC_NOFS | PF_MEMALLOC_PIN))) { + if (unlikely(pflags & (PF_MEMALLOC_NOIO | + PF_MEMALLOC_NOFS | + PF_MEMALLOC_NORECLAIM | + PF_MEMALLOC_NOWARN | + PF_MEMALLOC_PIN))) { /* - * NOIO implies both NOIO and NOFS and it is a weaker context - * so always make sure it makes precedence + * Stronger flags before weaker flags: + * NORECLAIM implies NOIO, which in turn implies NOFS */ - if (pflags & PF_MEMALLOC_NOIO) + if (pflags & PF_MEMALLOC_NORECLAIM) + flags &= ~__GFP_DIRECT_RECLAIM; + else if (pflags & PF_MEMALLOC_NOIO) flags &= ~(__GFP_IO | __GFP_FS); else if (pflags & PF_MEMALLOC_NOFS) flags &= ~__GFP_FS; + if (pflags & PF_MEMALLOC_NOWARN) + flags |= __GFP_NOWARN; + if (pflags & PF_MEMALLOC_PIN) flags &= ~__GFP_MOVABLE; }