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 70811C52D7C for ; Wed, 14 Aug 2024 02:20:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E2A266B0082; Tue, 13 Aug 2024 22:20:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DDA866B0083; Tue, 13 Aug 2024 22:20:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CA1D06B0085; Tue, 13 Aug 2024 22:20:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id A654E6B0082 for ; Tue, 13 Aug 2024 22:20:15 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 5B4521C2D47 for ; Wed, 14 Aug 2024 02:20:15 +0000 (UTC) X-FDA: 82449246390.28.EDE1DDA Received: from mail-ot1-f46.google.com (mail-ot1-f46.google.com [209.85.210.46]) by imf14.hostedemail.com (Postfix) with ESMTP id A4393100007 for ; Wed, 14 Aug 2024 02:20:13 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=KSpWXOTN; spf=pass (imf14.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.210.46 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1723601943; 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=f3V+DLbt+gBJxvflbIYvl5HUcut4u3GQMh9nwUHnO0o=; b=2BmpRxy5TJ7A6/lrzPGY9kmK6WHzzZD2SqzujKNfbFM/XH3E8U3uIf9Y6dVpfXepsVmYSI a0rarYv0ICKRS6wEYnIFvoXTQ8WV5ob/oIIhrPD3DDRSisw8xp4o/i3BaZRyV6+2DuOoAj PuYFBrxA4nW7joj0o+6wduKdb7EFlC0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723601943; a=rsa-sha256; cv=none; b=AF7PgS7WpQpJu2JJT/KcER+AsylxqTGNJggPZApPIkR/VmKDLGh4NK4tsTlm1Sv+Nl+9FK aTfpU3Rc5JZtjZkthHsYJrKzFgCImZLz3TUYL8AcFP4NHd2lrUr4kjQXOfLUgFQawBkR+M Hr7wa9XpICXJ4VC6x6SvwsSoBQFAT+o= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=KSpWXOTN; spf=pass (imf14.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.210.46 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ot1-f46.google.com with SMTP id 46e09a7af769-70938328a0aso3645329a34.1 for ; Tue, 13 Aug 2024 19:20:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723602012; x=1724206812; 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=f3V+DLbt+gBJxvflbIYvl5HUcut4u3GQMh9nwUHnO0o=; b=KSpWXOTNBDeqMmlymxYGD9c+eDruVzQeVkCj0oorJBlq6Xc99aS3zYljaCRPLFocge hAcNhqj2R6bYkstjhV+ap3eGXqTfHW0Dd2HTjtvVkivFCFBMWHL5heLUKtQgzYqTPX3K oSqtb1ZgERIOq3G+H//olxhRmF74aXbLX6evVO2rTYQJBEkoUgV512VooJfQONUPsbjc s63NBxsjO7a35MdLzyuqY7y/i88YI52konbfhod0SGXsTlhsowk3fi0krU+10stNsQZS fddSRdd68z+00V0a8Eepl4jNbIT9sNI85ioXwTb9IUp6hV4fl2O6FlZxlpvzKdkJrqnP stzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723602012; x=1724206812; 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=f3V+DLbt+gBJxvflbIYvl5HUcut4u3GQMh9nwUHnO0o=; b=uBL+hmDdPMcJbHfeSiRCT1GtSIoo/V7N2rdq6w7dYv0oQfpGJaV7BinpQhRhzeaxj8 IgrMZRpTT0PXyeEHdJe5XBzt6lzv8hDLYiEgQAsfPUXYgRc4/AyfNC7j7DLtG+SAw66l 42d8boX2ZgtUZ5nRmRPMn2JrXzIA8ZL8UBu0ZH2vqKVmArG8GsbHX6AnYo8yWfze6hBA JYAhqHiJoN8IwAZjUdYzsRU/qK03aPlP/mlRUUZ7lRkymwIgaQ6Ql+RT0JP03+7Hfuhr zSzzIe3G4g0xCdrvC45nXIS/VuEm8dxD497bRzE4cEHjq+NQ2DTxO6b+hN0ebV5uGrgX xgYQ== X-Forwarded-Encrypted: i=1; AJvYcCWI2a9VMOx/c9U1bUAMF7Glnpblu7dSyvHN/phOijXDbxCOoDUSo9wNtmfihB3acM64kbgtwMGQLg==@kvack.org X-Gm-Message-State: AOJu0YymhOb+/2U2nV1oQey30wcQtdUhR49Og6dwTRypbAD9Y1CAyzit ccLKdsnut9YeyJUkA8rT2imVqzsQjUCaKgtfW0Yb0QJr2XTyMNsZlmluUPzC9bbzqXE2OsCcWTo a2SNYk2Exxs9mYJfUaubNkJgRlqk= X-Google-Smtp-Source: AGHT+IFi/RRWEoYuIcX8DevLhOsamNomcbuQLC280BbkURJY8WIipWABfMbY2reYR9/jrfvyKYbpzMsESqWN3yrPd54= X-Received: by 2002:a05:6358:9144:b0:1ad:471:9b7 with SMTP id e5c5f4694b2df-1b1aab85b53mr160088755d.18.1723602012558; Tue, 13 Aug 2024 19:20:12 -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 10:19:36 +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-Queue-Id: A4393100007 X-Stat-Signature: ieghxwkt1omoz77x6k44gnq3hx5c3n34 X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1723602013-428764 X-HE-Meta: U2FsdGVkX19k+VV66VS3+X1WAViRY+chI9QkgR/ytMYyKRlLIvyE7iDyyweKGgGxyMqAqswgQhC/yn6uvw8yma9yQSl/eXi5lwAKSlLzV2QtZivdA+DIcj3byzA+Hfuav5BDMZ0GVYBCgiTHaC/FwR5+MHUElA/9o7vXEfYL/ngpV5gl1U55CX9HE+4mgbZPAnStEmrzho7UiqohX+njV35RT7k0pOe39+bXYL2D2/c2O2xMxxGv1YVn8YGIpdyo/xq22wkASYn3OB+MI95IEbNmK5Z9S1djeOnD0QAKOEFek1T9UD3/9FMZqLeHOCkmEnr1y/nYy0d2sAm5qJstFr3r4wPwnkKyR/5SvAiTaVI72i+LPhchSuLmc4uYl1hMJpWoCZDyqw1rmzf1cl6iEgxYKDqDnhzRBeT3GyPpy2SVs/UgLkBhWype6TiOn1TOU8sb2qFYYzat25T5VNcqycfsSStwqV42xkI90p8tRstQbd5ejsoFP0hADZf2stB+mRX58g1e/fwrKVhsHN25aPhw3WX8+BC1uVtUIvme8JafbTMH9YpU5KxqhRsAvHCHto5ZUfPalEzw1KpnH4PuOluHLdHgVAfAk/T3/g8hTJNpsTDKzqgv+KNAX46HZZ8OdzuVR0Q04pUv6w+oYE5n5c9bQfAyEH9Lxpv+2+0+2OFJuWfSXOUR8+NOXEZUHfk5WanEgn66pEzQ9O/shJlLp2coGhzWzQhSed3bTZD4u3B+rHCe1tcAM+YKIXDtN4afqor7GerTmBNvNVPKrwfPEdwgsOWd+dsI8Xnn00Q4qW+FOeOuCmVp/T3EUcZNAtG8YRV/C2Wne3L5GkltttPQ5L3Qjlja6k9nEUIJSEDnlRhREyRpx6m+jxZBJNMOUoKvp74h5kaKPy8BVw7o/X3fZG3xQydtU7uKRZAn1VCY3QNyFo9buG4aqkIkC+wDsehVs7Wp3gKb96uGBc/Xiof NRCBBa5A SYBv7KSHwO+MXAf/UgFQRqmcC1L7qjxz2iaW2K/QJwN3zSR+vbyLXWUW4lHb/umAzwDM8vvQepr8Ah7pSBoFtqMOK4l911sAneVLD6ah8kjm9dfckhpsAB6UhxK3lgje82sjoBis+uDilR5X2bP4Y7R4TGVZ0QmVE16mFTzlclrdMMltPFlClhxkvP22rf3U8ZxVsSxq2nJ0tk8Mq+qoXbiHKixbJNTwYI2C17tOAcebKEajNwnCngG1crLiFLONUNcRvuR5njA9nkNB+z8ybbrRRCHB/T/kyzKYCUhCW2Id2UvMZCzLT3NuSOdaE6xxf4gg3FoGSvTqE4v6R1uZrSe0prM5l/EGwjHLb4YZcuYHBomMn6YB6mENsiy5K2C64H8CT3mDkQsNbBPlIsCx7qr3oaOjSg20HurUmBjr3eq6BeejrCjAbhfiIpg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000452, 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 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 eab0af905bfc > > ("mm: introduce PF_MEMALLOC_NORECLAIM, PF_MEMALLOC_NOWARN"). To complem= ent > > this, let's add two helper functions, memalloc_nowait_{save,restore}, w= hich > > will be useful in scenarios where we want to avoid waiting for memory > > 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? > > 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. > > -Dave. > -- > Dave Chinner > david@fromorbit.com --=20 Regards Yafang