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 A2B28C3DA4A for ; Wed, 14 Aug 2024 07:33:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D1A336B0082; Wed, 14 Aug 2024 03:33:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CCA556B0083; Wed, 14 Aug 2024 03:33:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B91816B0085; Wed, 14 Aug 2024 03:33:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 955996B0082 for ; Wed, 14 Aug 2024 03:33:06 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 31196A784C for ; Wed, 14 Aug 2024 07:33:06 +0000 (UTC) X-FDA: 82450034772.11.45EAF21 Received: from mail-yw1-f173.google.com (mail-yw1-f173.google.com [209.85.128.173]) by imf06.hostedemail.com (Postfix) with ESMTP id 1C218180003 for ; Wed, 14 Aug 2024 07:33:03 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=PA2ISbiU; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf06.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.128.173 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1723620704; 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=zwXPWafGZ4R84u08fJaM2sWyE5li15RqmBSGPD0D4Cc=; b=1CrWiQLIZblMRpTRwCURu4gHXAm0XIjy4PeUULJ2sD6akW549i1UXZ1zCfQ4UfFC9vdx71 WCNBgrQUwjaZNG1f4BsY61CADgKEjmennqTOZ3UdsX1AME/r/oMJgCD2mOrfnZfIMWfEJI VBF/OYb6gHgpIsWEkHD46DtP6OpgZgY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723620704; a=rsa-sha256; cv=none; b=ErEUDL/6UmX+P7Oby/dC2ht+1qEwiViSsHxkDJAZmyjfUOgwLiwaTb1YM24qc6y4p8/YFy NKvsk9Qif2AHq8jkMMlq3PQReqhT7ES8kcNpUCt2wDw0GJ4odVVcoatMVEP9iyCB7Pt+wA YE1D0MKEQEkHgdpf5QgIszPMlKfnLK0= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=PA2ISbiU; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf06.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.128.173 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com Received: by mail-yw1-f173.google.com with SMTP id 00721157ae682-654cf0a069eso58357857b3.1 for ; Wed, 14 Aug 2024 00:33:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723620783; x=1724225583; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=zwXPWafGZ4R84u08fJaM2sWyE5li15RqmBSGPD0D4Cc=; b=PA2ISbiUizxfb/e4CEDCWET8vSg900i5HnDa+bNKWu0mfbdzawKSGK6aH4v9In4WxR gANti0ohe6Wo4pX5HwDmMK7mW6lm927zwLvE6XV2gJmaLy+Lm9xWVS55KPWPyqwpU/u4 c5ZvsEciJxgseIuxq7WDNldCFGxCmFdjS+PHgHSWYff7Wu12dBL6fTx/bxta3J+VrozZ 1Kwuwp1pxui0gXLphs8DW7E7o+zkDoeQQJ6cvrIoD49m/5POAVeegqnGHS1XfKhJjaMa Qlf1LMLWV2Fi1ac41SOP+dTq5KDm4wBTh+livz7jthEcNTCjrg+WpabPO5fnaEf7O/LY O/Qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723620783; x=1724225583; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=zwXPWafGZ4R84u08fJaM2sWyE5li15RqmBSGPD0D4Cc=; b=jy+mJeTdUFNj3W1r4wUYSfoK+jN/xvJ7hbpK4UxjCCnFxSNggm+WfXihKgluikYgPO W9m+Gt3+6t5CJqxoR3apv/U7YxJ0+aDfXcq45pMzGbo8fegf15zYSm6vhPKf9R0YJocY jSPuzkladoQyE9R27yDnEmnh6++jEr96ly3vzAbdTudGXCCR0svtERn5SBXzEb3081Ef yYgWVUy6n0ZwEDdLd4/BMF4Iqy3n4e6CqhwBIrltCm8IJ7Xw950k6nQbVGcQX3srLVCk RMufH5hKDioVRhhpG28I9Imf1pMnquK/MnF80ePdKMF8B7MZmz/b0DXiVVr3VFZFSUVQ yJ5Q== X-Forwarded-Encrypted: i=1; AJvYcCX0hXeWTKXdRUT3pYEgBj0Kndbb6KnczPcNGql08Ks5YF+UWu/PBsuz1SFp95N8XB4LY5PDOZXFp30S0Yc5soaVR1k= X-Gm-Message-State: AOJu0YxjARihxETiSa8q0vvEX5/FPZ/nlRvJIGQ3wY+df17rf4UvJWeU IplESxs9CmIrGEUWWOISPQwLrYv+uBr0+De9RroN0kwgrXBkXsP33V7NR0QEh144OdDAMQbjOpM FGjTeliO+6OB7tmpD3vBmXkQX9aI= X-Google-Smtp-Source: AGHT+IFIgfOsTL3/m+IXLqQJTTNiiwhMGTFu9w0Gc22QIClt0jG590ERbPVfH0qAxfggSQcvyjc5FwWIDIBjqT6Vouc= X-Received: by 2002:a05:690c:4241:b0:631:4da3:17ee with SMTP id 00721157ae682-6ac9a478578mr20017007b3.40.1723620783009; Wed, 14 Aug 2024 00:33:03 -0700 (PDT) MIME-Version: 1.0 References: <20240812090525.80299-1-laoar.shao@gmail.com> <20240812090525.80299-2-laoar.shao@gmail.com> In-Reply-To: From: Yafang Shao Date: Wed, 14 Aug 2024 15:32:26 +0800 Message-ID: Subject: Re: [PATCH 1/2] mm: Add memalloc_nowait_{save,restore} To: Dave Chinner Cc: akpm@linux-foundation.org, viro@zeniv.linux.org.uk, brauner@kernel.org, jack@suse.cz, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, Kent Overstreet Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 1C218180003 X-Stat-Signature: jpkzsm6gz7q4aqz4n3pp1oez4bqk79cr X-Rspam-User: X-HE-Tag: 1723620783-218136 X-HE-Meta: U2FsdGVkX1/8DCMXCh5ZQn6TSBSiYaCPp094GRSu0+hMXx0mLajN1qQDtdE6r4vzil17hxL/idA6ijJlYidBI4UFVCmxACzMSotpS06A0jGIFtkTNzM5M4wJU8GMRQhtNBkZoBLufu3AOS9t7SCItToKcnDHnmEfW8jimTQng6RCArabXFhbRJGfJfDECLhYX6oWKXI2VIgBsJ4BPmAR4XCB/uMZL3cAIh/JfO80MQddiWPPUa5LW+tx32GBygNIT05lU6+sm2Kn015APSlLIEuniKALVghGQDB40ylQCTCo4UWmzMKVx1BhxLy/Vx1clJHKFQL4Izba5DIYYwyZu3DIq2ropFJKcc2axcJG86P93PsroSgjjM6Mb94k5En4hJ6sN90xhcIuxcoSXKaL00G4kPeiYNaNWiTiXJ+n/kGkJLf5bT/SwGbmecjMfLf1ZA4p9bQG0CbkpEQ7t2WIrwJtAhiluqyGw6RJmd2LzivaYpEEcatHPfKtAIwkCCul+aWaPXMXnyw64osBY33vFtv2Rj8vBIV9kmthRFpI7wPJfiBWqgnaAOP84zcI2ZWPVg+q2JBsWhP5iQauGicFcS92bB6BcgnQ/xc+XvwPNPFS5i8iOI5W5FTfT8p86FDgF/aKm+af68u58xHs/Xrdjd39v70uXNjqUSR2fUk5BPbe8Iwe82SvDxYwpudnU0+tFz2uoRv9B0rpt1oq8Bfz8WuJHWKjUnZb6lKbqGRf975hA4d5dtPSum/3A3drnMdT/Y6Mku+rj1HXvydSIFfaQUpUlQ0R/pPxFEEFeekbR59WfFz1nUmx7f4/jR3I3nkVmjGGq7+kW8PLaxYUmlZllPyHqWe37u7p7zfsx6hG69TVtpVywBZYnpDCVWCaPVjGooKESnytah8GGfWZStDpOKa/wtXXV/1bXsvVkg25LIh+OKh+eUMf6DFf+MHeFm6pUoBrIkq15Y/r2F9OPyg H7xcOxoZ 0scK+oSSYRJyGE++TMXen/Bd/SoC92MT0R/2NuRZbQAi7lKk+EGOJfgoLVkcgeZGapTIo1lV0gMwgLPMZZnt/8BDhpMdJQ8aWJKmINTuaNHFpqv6JvfcxixLJ3g2YHho+URJkIZ0E5t/ronXbE5wqx1iQ1di3LF5gSrj4sY9tRqvUXOEhOjS1hRB0jLY20UYymdlgKQ4fJhFOLc2Vit2wzYAChyeIxjyJrhljQCpKJE2n+s6nsMMhapYP73gRmxNraokkrlHZvRz2zILi0IY9DE2gzAu2huP+CP0LCol4qdor2BE9n06SFwEh/YgxBtB6C0/uj608pkvMUGfsF6UplB3KhHbpcbV+HHNAtaEjVoFmwHEwgwDhXZR7RyVsJChLN8gHN/nNIHhYWv5ASYe5oRenRBmSWdnOfoundNb5MGTT77uLQVchwVxpYg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.002946, 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, Aug 14, 2024 at 1:42=E2=80=AFPM Dave Chinner = wrote: > > On Wed, Aug 14, 2024 at 10:19:36AM +0800, Yafang Shao wrote: > > On Wed, Aug 14, 2024 at 8:28=E2=80=AFAM Dave Chinner wrote: > > > > > > On Mon, Aug 12, 2024 at 05:05:24PM +0800, Yafang Shao wrote: > > > > The PF_MEMALLOC_NORECLAIM flag was introduced in commit eab0af905bf= c > > > > ("mm: introduce PF_MEMALLOC_NORECLAIM, PF_MEMALLOC_NOWARN"). To com= plement > > > > this, let's add two helper functions, memalloc_nowait_{save,restore= }, which > > > > will be useful in scenarios where we want to avoid waiting for memo= ry > > > > reclamation. > > > > > > Readahead already uses this context: > > > > > > static inline gfp_t readahead_gfp_mask(struct address_space *x) > > > { > > > return mapping_gfp_mask(x) | __GFP_NORETRY | __GFP_NOWARN; > > > } > > > > > > and __GFP_NORETRY means minimal direct reclaim should be performed. > > > Most filesystems already have GFP_NOFS context from > > > mapping_gfp_mask(), so how much difference does completely avoiding > > > direct reclaim actually make under memory pressure? > > > > Besides the __GFP_NOFS , ~__GFP_DIRECT_RECLAIM also implies > > __GPF_NOIO. If we don't set __GPF_NOIO, the readahead can wait for IO, > > right? > > There's a *lot* more difference between __GFP_NORETRY and > __GFP_NOWAIT than just __GFP_NOIO. I don't need you to try to > describe to me what the differences are; What I'm asking you is this: > > > > i.e. doing some direct reclaim without blocking when under memory > > > pressure might actually give better performance than skipping direct > > > reclaim and aborting readahead altogether.... > > > > > > This really, really needs some numbers (both throughput and IO > > > latency histograms) to go with it because we have no evidence either > > > way to determine what is the best approach here. > > Put simply: does the existing readahead mechanism give better results > than the proposed one, and if so, why wouldn't we just reenable > readahead unconditionally instead of making it behave differently > for this specific case? Are you suggesting we compare the following change with the current proposa= l? diff --git a/include/linux/fs.h b/include/linux/fs.h index fd34b5755c0b..ced74b1b350d 100644 --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -3455,7 +3455,6 @@ static inline int kiocb_set_rw_flags(struct kiocb *ki, rwf_t flags, if (flags & RWF_NOWAIT) { if (!(ki->ki_filp->f_mode & FMODE_NOWAIT)) return -EOPNOTSUPP; - kiocb_flags |=3D IOCB_NOIO; } if (flags & RWF_ATOMIC) { if (rw_type !=3D WRITE) Doesn't unconditional readahead break the semantics of RWF_NOWAIT, which is supposed to avoid waiting for I/O? For example, it might trigger a pageout for a dirty page. -- Regards Yafang