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 0F2FAC4828D for ; Wed, 7 Feb 2024 21:05:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 776AE6B006E; Wed, 7 Feb 2024 16:05:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7269C6B0082; Wed, 7 Feb 2024 16:05:30 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5EEEF6B0083; Wed, 7 Feb 2024 16:05:30 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 4F7036B0082 for ; Wed, 7 Feb 2024 16:05:30 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 1EDCC805EB for ; Wed, 7 Feb 2024 21:05:30 +0000 (UTC) X-FDA: 81766238820.19.2751D74 Received: from out-189.mta1.migadu.com (out-189.mta1.migadu.com [95.215.58.189]) by imf25.hostedemail.com (Postfix) with ESMTP id 3D442A0010 for ; Wed, 7 Feb 2024 21:05:27 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="fIp/rNbe"; spf=pass (imf25.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.189 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1707339928; 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=v8CYDjSXRSAYFDMu0VIyasgvuYSnNMDTK7U3cR8itbk=; b=feF6FDk4XxZsUKED43Ja15IblU0ZZiSyCvf5n15+8Rh7arXSFRi2rg+QW0D5BwMOolOOPY HIBTAFaxRQokJd2Qmmo55Yaug2clrqPq1H8+8J8Nc6pGh05jsK6WqEZJa8kXMwk93BErTS 5AdGb1YKl0MQ5vH6N4Oj2A/zZInu98o= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707339928; a=rsa-sha256; cv=none; b=NuDBm8Wu5JwB3LOkDWAc2+m9bXFF8jcZzU0se+Ua6rhpVLv5VcMQAhe9U1MRedAthEpIA7 60RgIvzFR1NjZ6UMQhygMG71Z75pylzHfYgfheuFguUDoibBuUJ0bbBpIWH/tWoOtkZ65C IMKMFmVv1t9637CKrlFWLFYX4Mrzr1o= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="fIp/rNbe"; spf=pass (imf25.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.189 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Date: Wed, 7 Feb 2024 16:05:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1707339926; 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=v8CYDjSXRSAYFDMu0VIyasgvuYSnNMDTK7U3cR8itbk=; b=fIp/rNbex5C6060enRU4y0dTaSeB3MGWjQCh0klkCEOydxmpKNldRBomSmctKTyExxjPms D+eW69OXEbc5LYZbLrnu3/1UrF/A29Gr+lzH7braAu9Ndrjgc9rESifWXniKByCZW5XR3v bP5nho9Sx0HIn81GGI/wfShQl8ii8aU= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Vlastimil Babka Cc: linux-mm@kvack.org, Matthew Wilcox , Michal Hocko , "Darrick J . Wong" Subject: Re: [PATCH 2/3] mm: introduce PF_MEMALLOC_NORECLAIM, PF_MEMALLOC_NOWARN Message-ID: References: <20240206215016.961253-1-kent.overstreet@linux.dev> <20240206215016.961253-3-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-Stat-Signature: fo5fnys73tgc31q6m6qmnxxnij6nse4o X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 3D442A0010 X-Rspam-User: X-HE-Tag: 1707339927-90749 X-HE-Meta: U2FsdGVkX19YZw4xfn6ZYnN7gEgXIEBltnqfrGqrf4gfT42BQAODEY7SrtKyxSAPy4Xv8Omv2/OnFg7n6vDh70cmPAq95/8DbKESQjhFmxqtFxVXuT5TaiR2BAmFePWMabShNlib4oFfwbFp3HCVpURdLCSWrTFOiukZoXU4v/j2Vhl46A9+NU406KNqOiLQhlcd+2PRbos6lQq4MGeBlne8ZDJVQMS8YUaaNfjlt35pHOKVi50QuQ6hKkkrdp0Vqfjyb+IlPPADQUXtyY3cd9ZEwq2I7HYhObyddXR2WBzA5IqWdoEL94XQ8WKjq1DberyGpbYD09hR9VwqANxP9DhE9K9kC1slp75WqGVA9tdR26pSigt0T8+R50qr79tOADYubVO9R4J4e3RBR7A7bhbqGqtsiUKR2RghTjlAw2Qkf50N8HJK55dU34NObxRo3PdcffqWY2ikCS2mJ2it+0zTZqEBPF7gjj2CHKIDS+43HAMf0aEo0qn3Z+7JjLAS6WmTIB/F6FOXtA3VXROItl23AaURjj/BXb1lZBZhAo5T+lutmLrw0fEZL3S4V/oSd6/gmqStNjwoS4n+Yk85zhwZWCeviXFLKEurTq+uUL9lUCIAMnn7v468ph5p5ohCY7dha/h8PA9pdBHXZB/JQzvPVXBUywppV6Bo5x6UPw+HEC6qefc7r5GMbK8N601892lFwTbA01tv2zwrhZDzF8iMFta6dg6mA3mJwBGO1rWA6SekN1Z4+CXyf8ee79sBMJKQUkQATkPBp3Fa5oSxaV9b33E7T7Dr+Svha2d1kXuDC86sMlX6jiGFjpKmAbpiCmjkitqeCOacD6PdaQpReA== 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 Wed, Feb 07, 2024 at 08:24:33AM +0100, Vlastimil Babka wrote: > On 2/6/24 22:50, Kent Overstreet wrote: > > Introduce PF_MEMALLOC_* equivalents of some GFP_ flags: > > > > PF_MEMALLOC_NORECLAIM -> GFP_NOWAIT > > In an ideal world, this would be nice, but we are in a world with implicit > "too small to fail" guarantees that has so far been impossible to get away > from [1] for small order GFP_KERNEL allocations, and this scoping would be > only safe if no allocations underneath relied on this behavior. But how to > ensure that's the case? Fault injection. You can't know if code works if it never gets tested, and if small allocations don't fail in practice, then you need fault injection. But there's a code pattern that absolutely requires GFP_NOWAIT. Say you've got locks held and you want to allocate memory: p = kmalloc(GFP_NOWAIT); if (p) goto success; unlock(); p = kmalloc(GFP_KERNEL); /* unwind and retry, or tryrelock, depending on what you're doing */ that is - try the allocation nonblocking, then unlock or unwind, then try it GFP_KERNEL. bcachefs uses this heavily because we've got bch2_trans_unlock() and bch2_trans_relock(); relock succeeds iff nothing else took write locks on the nodes he had locked before - so we can safely use GFP_KERNEL without causing deadlocks, only the occasional transaction restart. but: the first GFP_NOWAIT allocation, before using GFP_KERNEL, is absolutely required - calling unlock() has to be a slowpath operation, otherwise it will livelock when multiple threads are contending for the same locks. More broadly, there's a bunch of other GFP_NOWAIT uses in the kernel, and we're _not_ going to kill them off, and we are trying to kill off gfp_t for this kind of purpose - so we need this.