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 203E5C48BF6 for ; Mon, 4 Mar 2024 00:20:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 460766B0095; Sun, 3 Mar 2024 19:20:35 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 410E06B0098; Sun, 3 Mar 2024 19:20:35 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2B1566B009C; Sun, 3 Mar 2024 19:20:35 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 157C96B0095 for ; Sun, 3 Mar 2024 19:20:35 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 995BCC0954 for ; Mon, 4 Mar 2024 00:20:34 +0000 (UTC) X-FDA: 81857450388.17.862FB34 Received: from mail-pl1-f180.google.com (mail-pl1-f180.google.com [209.85.214.180]) by imf27.hostedemail.com (Postfix) with ESMTP id 8CEEB40006 for ; Mon, 4 Mar 2024 00:20:32 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=aAezn52I; dmarc=pass (policy=quarantine) header.from=fromorbit.com; spf=pass (imf27.hostedemail.com: domain of david@fromorbit.com designates 209.85.214.180 as permitted sender) smtp.mailfrom=david@fromorbit.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709511632; 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=n7+u96xPcBF8UnwMQsi6zps3kKJmqNLYGPjj0sLBatY=; b=wtwTgD2XeIMfmFC1CJs1D1cyreietFaS0ymzMxf4/x94HXkHiRDpetAyXW85CwDX7ZTXjL 2XjlE+fVYaSzYOrLc4+RbTR9cgt5Z6nkLOTEzowDNKCaYX54Z/8tpFzJgd53iygxcXFDCO 3VOq0rWjIN4bII0AwHJRuh9Ghl6FjHU= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=aAezn52I; dmarc=pass (policy=quarantine) header.from=fromorbit.com; spf=pass (imf27.hostedemail.com: domain of david@fromorbit.com designates 209.85.214.180 as permitted sender) smtp.mailfrom=david@fromorbit.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709511632; a=rsa-sha256; cv=none; b=FGUc+CqnGdHuKFryAi2Ojy7fqRgV1YXrLljwV6z4DnKHsbVdkEQcPmLwIpcIyG0XxXo1h5 p8O0kIJ2+s/WatpnjRLS06IRU8ixG8exL3BbTeGjyKNq4yVV3FpYfA5XfECfSXt/bQE6Li Q8datAGlmYi6W+CdO53Cl99UqqIJkdE= Received: by mail-pl1-f180.google.com with SMTP id d9443c01a7336-1dd01ea35b5so4021555ad.0 for ; Sun, 03 Mar 2024 16:20:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20230601.gappssmtp.com; s=20230601; t=1709511631; x=1710116431; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=n7+u96xPcBF8UnwMQsi6zps3kKJmqNLYGPjj0sLBatY=; b=aAezn52I2XiY/q0NJVH9rJzPfSeBlLYL/+L+7xZXFVRlzfBOhCjCnsaQxfefqnnMXC rt/E0V6pDJMOg5/OTXNayFE9vHxjSBKt1UbSRrFoRHt2J2oziFvxNxCYs99lur/FweRi 1kK1lcx1PNaSj/AeQ/5B/C0I0+WasMCj5GUa5v6aI+XoscGTbmJjFLMKmhwRhD06h8lN RzNEQp7JQRpDqUCEofYno025+pf9XJpJMFiovNbIkpvdKs/THY5SiKmrUzcDsRZyvwz2 rtf0jEv5PiC0cIumrcpbCToRROA1ymSs//Gx2vJgRHNNSsAodvYvi63SISBpebf9AJte P7JQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709511631; x=1710116431; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=n7+u96xPcBF8UnwMQsi6zps3kKJmqNLYGPjj0sLBatY=; b=rWCrREJ1ASjGoCCKZZ33L4xYvqv9NEDs0UvoZYXpJSNh0CzQPwP9V1zfXTWM4QHWOF zN1uCH58XLxzVsYEHbtW0424Xdga+eTodhDEkV+U0d+MZIfA3g4xe7bMEOsftGDxcKLL 5AyBx3Cosk4FLYEGBq+lg8VHRaX8RZGoDzwvzA0mXnFh2ZrWAG7zDazQti6U5gsCpedw Ym+CKiJV1LLpb/z6k0K6szt1pH90fwLAyH5Jsdmo8/O0JrFt2bwQUiXdAsAWeKarbWph CM9o9bu1zY38Q+XCDY3Ir+EPX3UaI5s5accX7haM/K6jpbhUWFiu9A7vr5w1/GMToALH zArQ== X-Forwarded-Encrypted: i=1; AJvYcCVzLRj3qFvrQIUf4NhOJB5fUcgtwO2TD+P7L6A011psBBmN/80+RdEnvst5a+3WNnN8Uq7OXMyMmU3h5oB7jtNzzVs= X-Gm-Message-State: AOJu0Yw53wxw090TVNM08dRbUJ0/NDZeChyH3jt0TlGfekkf5tfnKrur N7cULxYAAXifnupvUjyyLSBIxQ6KDEC547auIBuZKiVKWzykdjXfsPnmibr8No8= X-Google-Smtp-Source: AGHT+IHHqRVwbzhDqGZzQPZTKp/5e8rUMV/ODbLbXFp89J0IezoxnX3dyYeolNS6GNZvX2KpejwDhQ== X-Received: by 2002:a17:902:e746:b0:1db:7052:2f45 with SMTP id p6-20020a170902e74600b001db70522f45mr9138784plf.61.1709511631245; Sun, 03 Mar 2024 16:20:31 -0800 (PST) Received: from dread.disaster.area (pa49-181-247-196.pa.nsw.optusnet.com.au. [49.181.247.196]) by smtp.gmail.com with ESMTPSA id d10-20020a170902ceca00b001db9c3d6506sm7119202plg.209.2024.03.03.16.20.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 03 Mar 2024 16:20:30 -0800 (PST) Received: from dave by dread.disaster.area with local (Exim 4.96) (envelope-from ) id 1rgw4B-00Efo9-39; Mon, 04 Mar 2024 11:20:27 +1100 Date: Mon, 4 Mar 2024 11:20:27 +1100 From: Dave Chinner To: NeilBrown Cc: Kent Overstreet , Matthew Wilcox , 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 Message-ID: References: <170925937840.24797.2167230750547152404@noble.neil.brown.name> <170933687972.24797.18406852925615624495@noble.neil.brown.name> <170950594802.24797.17587526251920021411@noble.neil.brown.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <170950594802.24797.17587526251920021411@noble.neil.brown.name> X-Rspamd-Queue-Id: 8CEEB40006 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: jopnidwcpegbi7xam63hysumwnmh5jwg X-HE-Tag: 1709511632-495920 X-HE-Meta: U2FsdGVkX19qS/UaQkSO8S1W4Ha0SsGIJcmJ+5lGe5dqsS4l1ZjfQYkQIf++trNc2QQisSu5ZQ+qcDK86mUi++xTE/Fq0A9VM1OrQadobREVIf359F62efPHdNGT09nrIPH08FZsJX8skBNPprbt2yjidnoaqKpyxidengfc8dYB+oXUDcarWAFwEi1wmY+Tz2IKtkjTv0POTtglrDpHZH9BNnlXDnLeX9G+B/jilV5t3jO2A0TkvgJJIy6/eNNK/soF1rCQGEKQBVAJRW0eSguKpj3K33nS5+XoqSKCqtKb9AMyurqtZ/8EGSffIvEIkgIbb/Dc4jnXyf0HYJR089Njmuf1kX5uaksb/9J44SjjqkyjNn1Qb33NAX65qJvn31IjMOi+fXcxi7so7WYUNy7uJF4zCMicuZtTMNKxi5KMe348AqO6oIf6U1SU0WAxAkMcBxlAhmUyRYL87en1jL5dvv8LhTDZFP0AUNhwlTKGe8LtCjYP08//c67FMi+Rbxv13hu6FY3OMWkDITlWJbNOOiWmRqko6EchSOR37K4l/3wAvIJKoc2kIEavtz3bU51ndCrb1pzgZy+XVUaJs/AoMyxbeb4vfXLkWRTKLAE5MmvmtkJ9PCsfiVnguq0DABMGXcjPoTRHGIK3ANNYwvyfycLMZ6Zt2QXxTl6UY6Fw9TpMNFKwmCEexy/gdV0bBFcqOXC9wz++9b9LT+ll/UR7bKcae03uW3dhMKXH0bHYUgWNS1rq0KmmOxE2BqcAFbTBMEVXjv19oP4ibQUFHpnRsz7H9HNPUHvpU6yfc8xxIgSouZx5Z/qmBZSbncPWF/6GZf0D4dqkVSzroF0zuRXE9N5FcR+g3Y7MISbQmxvVNgY5Ujr6wpc3Z2uopdRDDBWpKCZfxXqzID8uKU+zcCQtTVkA0HU6eustqOQ7r+WAcFbnL2gpt1pYYgk48+QSHVrakf8tFwD5wxcpEO5 CQNCSVT3 9gaYyP0QcSeNV8V55Nj0xTj9ahfVoQ/6LfWAr+xtBoBJlbKC01AS40UR0tzQLBnT1EC9u2tM8qG8/n2sr85GvAhVMjIorl464hXae2nz3cBvnzaoAvMV4wu3krZ+0xdQkV8Wl+H71Ac5tv2PYC0LZTMoIVtcxGZXfEbrwLq0UMpQClyg06yKfKZ8UyWLyRBhj+02ER0L52MxHf0s2zDV9otbGWmc22LavQtWaMCr7r9W+8kBv6BsBXdq9d2ONHr0HFji4wr2RaDjvJDdiVk6PiAe6UBvCAOtL8NfIejrRF0PevI5Zow4jOxsfhFLWcoQlEjkoQ+gN6EvYtscs2tryB1WvnRExsLGSLLKE7uAiUWk8Cjo3BL+VA+myqGlRSQJD/Q81XrNTDSJo4bhPVHbaQKwgC+ybsru1g9mBSygFi3MMG7O9joNOBE8YKEieOB9K8U5R 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, 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 Make this the default, and we don't need a flag for it at all. > 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. KILLABLE and RETRY are the same thing from the caller POV. Effectively "GFP_MAY_FAIL", where it will try really hard, but if it there is a risk of deadlock or a fatal signal pending, it will fail. > 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. We're talking about wait semantics, so GFP_ATOMIC should be named GFP_NO_WAIT and described as "same as NO_RETRY but will not sleep". That gives us three modifying flags to the default behaviour of sleeping until success: GFP_MAY_FAIL, GFP_NO_RETRY and GFP_NO_WAIT. I will note there is one more case callers might really want to avoid: direct reclaim. That sort of behaviour might be worth folding into GFP_NO_WAIT, as there are cases where we want the allocation attempt to fail without trying to reclaim memory because it's *much* faster to simply use the fallback mechanism than it is to attempt memory reclaim (e.g. xlog_kvmalloc()). > I don't see how "GFP_KERNEL" fits into that spectrum. Agreed. > The definition of > "this will try really hard, but might fail and we can't really tell you > what circumstances it might fail in" isn't fun to work with. Yup, XFS was designed for NO_FAIL and MAY_FAIL behaviour, and in more recent times we also use NO_RECLAIM to provide our own kvmalloc semantics because the current kvmalloc API really only supports "GFP_KERNEL" allocation. > > Deprecating GFP_NOFS and GFP_NOIO would be wonderful - those should > > really just be PF_MEMALLOC_NOFS and PF_MEMALLOC_NOIO, now that we're > > pushing for memalloc_flags_(save|restore) more. This is largely now subsystem maintenance work - the infrastructure is there, and some subsystems have been converted over entirely to use it. The remaining work either needs to be mandated or have someone explicitly tasked with completing that work. IOWs, the process in which we change APIs and then leave the long tail of conversions to subsystem maintainers is just a mechanism for creating technical debt that takes forever to clean up... > > Getting rid of those would be a really nice cleanup beacuse then gfp > > flags would mostly just be: > > - the type of memory to allocate (highmem, zeroed, etc.) > > - how hard to try (don't block at all, block some, block forever) Yup, would be a very good improvement. -Dave. -- Dave Chinner david@fromorbit.com