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 98965C5475B for ; Mon, 4 Mar 2024 01:27:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 02D066B0072; Sun, 3 Mar 2024 20:27:32 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id F1EDD6B0078; Sun, 3 Mar 2024 20:27:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DC0596B007B; Sun, 3 Mar 2024 20:27:31 -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 CA79C6B0072 for ; Sun, 3 Mar 2024 20:27:31 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 5C74112094C for ; Mon, 4 Mar 2024 01:27:31 +0000 (UTC) X-FDA: 81857619102.20.6D8626C Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf13.hostedemail.com (Postfix) with ESMTP id 1146A20005 for ; Mon, 4 Mar 2024 01:27:28 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=atb0aJov; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b="cxZ3s6R/"; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=atb0aJov; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b="cxZ3s6R/"; spf=pass (imf13.hostedemail.com: domain of neilb@suse.de designates 195.135.223.130 as permitted sender) smtp.mailfrom=neilb@suse.de; dmarc=pass (policy=none) header.from=suse.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709515649; a=rsa-sha256; cv=none; b=0SOcagd4tPp8dmMP6UoM+fV2YvaNbP99OGSbQ4YFg4PeYSa7w3GOzSsNhkEF6NFnrNoo8o LoraWCgCVTfx6RyCX2neaOv4tx9MzoHaUN4rR7T8wFL/BOlRVrs0nHlPshdT8VlKBUnzRu ssxRSoNtqG/1xMA6xptn0HsaEcumBQk= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=atb0aJov; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b="cxZ3s6R/"; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=atb0aJov; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b="cxZ3s6R/"; spf=pass (imf13.hostedemail.com: domain of neilb@suse.de designates 195.135.223.130 as permitted sender) smtp.mailfrom=neilb@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=1709515649; 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=VY73jSbHy5FdrIntQy28JDy9NrIs5O6B8GeLuqNrspw=; b=B0duEHN68GcbuzzGNlEwi/sJbcVTe0KHSevVpeEzvxM+bTq5sF+P6dW7+6c50WlbOh7f22 r6iKFyksDUOX6V6VHyr6q6rL9C9VBDgi1n50vFnT8Mlgh8hjsNKS4pHoCMnMIRxTEmnoFv MIC0SPWOV/aA9X3hsFszHR1mTaDOTE0= 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-out1.suse.de (Postfix) with ESMTPS id 27C9D4D36E; Mon, 4 Mar 2024 01:27:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1709515647; 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=VY73jSbHy5FdrIntQy28JDy9NrIs5O6B8GeLuqNrspw=; b=atb0aJov6tcmhbj/DMo/TGs2Q4JyCAEu6Renbj48+2+LWYaq/odCc4t/WSQKZQzx7eLsSy zB5lHC+IktKhsQDH7w+oFwRFau0SPL4Aa74ecfGKRR2yEYP2+z0zpLZOV4T9iE16WHYCBJ hrXQUjsmPXB5qGY5LKj/jTwS6cAKyIo= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1709515647; 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=VY73jSbHy5FdrIntQy28JDy9NrIs5O6B8GeLuqNrspw=; b=cxZ3s6R/fLiJHptnYMYF5wueWZ0db8ds9J5KuQA1D56LPUq5gHHl0KU/0Dc6/sluVHK7fS j6b9PuBR52R/laDQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1709515647; 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=VY73jSbHy5FdrIntQy28JDy9NrIs5O6B8GeLuqNrspw=; b=atb0aJov6tcmhbj/DMo/TGs2Q4JyCAEu6Renbj48+2+LWYaq/odCc4t/WSQKZQzx7eLsSy zB5lHC+IktKhsQDH7w+oFwRFau0SPL4Aa74ecfGKRR2yEYP2+z0zpLZOV4T9iE16WHYCBJ hrXQUjsmPXB5qGY5LKj/jTwS6cAKyIo= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1709515647; 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=VY73jSbHy5FdrIntQy28JDy9NrIs5O6B8GeLuqNrspw=; b=cxZ3s6R/fLiJHptnYMYF5wueWZ0db8ds9J5KuQA1D56LPUq5gHHl0KU/0Dc6/sluVHK7fS j6b9PuBR52R/laDQ== 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 5F5841379D; Mon, 4 Mar 2024 01:27:23 +0000 (UTC) Received: from dovecot-director2.suse.de ([10.150.64.162]) by imap1.dmz-prg2.suse.org with ESMTPSA id x/2mAHsj5WVrDAAAD6G6ig (envelope-from ); Mon, 04 Mar 2024 01:27:22 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 From: "NeilBrown" To: "Matthew Wilcox" Cc: "Kent Overstreet" , "Dave Chinner" , "Amir Goldstein" , paulmck@kernel.org, lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, "linux-fsdevel" , "Jan Kara" Subject: Re: [Lsf-pc] [LSF/MM/BPF TOPIC] Reclamation interactions with RCU In-reply-to: References: , , , <170925937840.24797.2167230750547152404@noble.neil.brown.name>, , , <170933687972.24797.18406852925615624495@noble.neil.brown.name>, , <170950594802.24797.17587526251920021411@noble.neil.brown.name>, Date: Mon, 04 Mar 2024 12:27:19 +1100 Message-id: <170951563963.24797.10928820769529800242@noble.neil.brown.name> X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 1146A20005 X-Stat-Signature: 79bq5kia7e7xs3aywp64epzqtcg74mrf X-Rspam-User: X-HE-Tag: 1709515648-544671 X-HE-Meta: U2FsdGVkX19rHJS7luzoW9pDDC3fQwOUeNDksUr+CHWqLHN6yxVnAZ7XwxUSbVlQD4kHTumnv8wgTCJzAQKTlKzG3ga23WMPDvGHJ7x3a+LkC6h89Bo25IJCb//x3XDQs0Ml4uIVNFFHjJJhkA5c+w+b8RdJAhbEqgGqUR/dkA4ZO7DgK2JEkGzwVEDoMsVLSP3MtVCVvQlvXxRVFZ+KseTF39FPKcbDpbH+bKGsVRTRUY7p/Y2zWhoJQbwC9Laz1aebK7860CcESHeuMmf5dht9VXR+jtC1+7GS+jv4tlei8jYKfKROIk3oOfgw3sz/MhuP6ev/RGOe1Gir7Hfoh+2DNYjrLW95y7SDjlFnfB9Rf5PHUl7IAgz2cKJ3CORLqey3G6dNU6Tk24JMA1pXX/rLGjTKY5gFT98g8Ca49RMmw+Qzry24+AAV/EZFJ/w3e59C/OCuPgyLM9LX6HT1gg15HG9Uai+NlVT2wt0+BVCv3LBkr+ACI68V4Ep2S9q76MnXgq/79QC76yLIofkxmuHTchLdk2nj6OXVSIjtmoleiS+u6R+3DlNdFbkaKzG5kYBPnz49tLJIpqddPir7f4+7fMoQnNyLK/oeqd/OySeaxr0MtQbCnp15ePvgNoY3crGc/TMBJAIRtWd8r2GXilLSqWDjemdH86N3ksjZAu7XBPWakwXa2bn/8aokYt6xKAY9pMw6dPLCvAB/Q3EBqqzMs9k97LwRIG+s/4GDUU93AnE0xo3+/Ml3GGs+1gvUeYJvOk8XaYNWfCpIu6oB2rAJxpdqxqCOxhOHqX/Inko3Go4IDVrOXind0BWRa+t/jw96MwA4O1s9K62D7uVloGGPyoQuonm2loLihMKX8UwUQcxBX7NKf1exN1wppSgTP0M/ND1piAIsxCpXuMwRUt6Pue8RVSlj3WIEMQaQLR7Vhof1nMU56beVgMPLHEkhdkPm6PtagyCf1h/wQ8m qdPMROJm AEiuKr/NeMp00JTPb41DNkvVH/4OjqhJwEmtaN7YtwdqwHgcp+eVLFuydNAw/hgHTH1okz1lvLbyIDN2jeA/wCc/HXN97lQDj5/dEk//z3DEU4SSJV04ndX3XVSDnloyu1gekuZZC0XLhkL68YEyEf/wGg5MfFVYct1avYaOg/AT85k1Nfq/QQcQknDyjQPs8+QaHaMwijqs7j3P9Iwx1wn2ZdBYAdhNFfXqL 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, 04 Mar 2024, Matthew Wilcox wrote: > On Mon, Mar 04, 2024 at 09:45:48AM +1100, NeilBrown wrote: > > I have in mind a more explicit statement of how much waiting is > > acceptable. > > > > GFP_NOFAIL - wait indefinitely > > GFP_KILLABLE - wait indefinitely unless fatal signal is pending. > > GFP_RETRY - may retry but deadlock, though unlikely, is possible. So > > don't wait indefinitely. May abort more quickly if fatal > > signal is pending. > > GFP_NO_RETRY - only try things once. This may sleep, but will give up > > fairly quickly. Either deadlock is a significant > > possibility, or alternate strategy is fairly cheap. > > GFP_ATOMIC - don't sleep - same as current. > > I don't think these should be GFP flags. Rather, these should be > context flags (and indeed, they're mutually exclusive, so this is a > small integer to represent where we are on the spectrum). That is > we want code to do > > void *alloc_foo(void) > { > return init_foo(kmalloc(256, GFP_MOVABLE)); > } > > void submit_foo(void) > { > spin_lock(&submit_lock); > flags = memalloc_set_atomic(); > __submit_foo(alloc_foo()); > memalloc_restore_flags(flags); > spin_unlock(&submit_lock); > } > > struct foo *prealloc_foo(void) > { > return alloc_foo(); > } > > ... for various degrees of complexity. That is, the _location_ of memory > is allocation site knowledge, but how hard to try is _path_ dependent, > and not known at the allocation site because it doesn't know what locks > are held. > I'm not convinced. While there is a path dependency there is also location dependency. The code at the call-site determines what happens in response to failure. For GFP_NOFAIL, failure is not possible. We cannot allow context to turn NOFAIL into NOSLEEP because context cannot add error handling. Consider mempool_alloc(). That requests a NORETRY allocation because there is an easy fall-back. Is that a location dependency or a path dependency? I would say it is location. Of course a location is just a very short path so it is a path dependency too - but is that perspective really helpful? Certainly I could accept a GFP_WHATEVER which uses NOSLEEP if path context demands that, and NO_OOM otherwise. Thanks, NeilBrown