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 692E2C3DA4A for ; Thu, 15 Aug 2024 02:54:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C3B4D6B0083; Wed, 14 Aug 2024 22:54:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BEA2B6B0085; Wed, 14 Aug 2024 22:54:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A8A9F6B0088; Wed, 14 Aug 2024 22:54:24 -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 85E146B0083 for ; Wed, 14 Aug 2024 22:54:24 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 34A9E160BE1 for ; Thu, 15 Aug 2024 02:54:24 +0000 (UTC) X-FDA: 82452961248.01.29B3481 Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com [209.85.214.181]) by imf16.hostedemail.com (Postfix) with ESMTP id 2A342180003 for ; Thu, 15 Aug 2024 02:54:21 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=UCXOknk3; spf=pass (imf16.hostedemail.com: domain of david@fromorbit.com designates 209.85.214.181 as permitted sender) smtp.mailfrom=david@fromorbit.com; dmarc=pass (policy=quarantine) header.from=fromorbit.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723690425; a=rsa-sha256; cv=none; b=uY2D8vyFTwLCx92NzqRoS5gerwdBSItWnKUt6xAnxAoAlBdmUIIPB3YxpLikrJzwKeE1PW gw6xcETyUkI3wGgaIHo0RpnZjnWYwjJ1b7SjvKIUCH0UOOLg5LEYoYTTPU6G54Ju2bNi7G yT7jzUK10SWDMkGAfW/FGU+YuVLu4ng= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=UCXOknk3; spf=pass (imf16.hostedemail.com: domain of david@fromorbit.com designates 209.85.214.181 as permitted sender) smtp.mailfrom=david@fromorbit.com; dmarc=pass (policy=quarantine) header.from=fromorbit.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1723690425; 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=gPCANlIQhbsZqCNbnbbPmOo9t3kSZJf75lEGK3ZyGfQ=; b=iB0R34m5PVagbDFYTVsuBXrLAckw3ODcwzg0FNsoVy8d7mAYbRR5WDUwW6lpd1R/n+H6zo MhRLwi2JGEb2tsjo6e1si/5MLW5I7cja46AyVbv3bPlx+TsmTU5TRxwbaHuJCtY5FiARui HL7OYImd+Nh8/EENdHDrOBPRzAJygqc= Received: by mail-pl1-f181.google.com with SMTP id d9443c01a7336-1fc65329979so5012145ad.0 for ; Wed, 14 Aug 2024 19:54:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20230601.gappssmtp.com; s=20230601; t=1723690461; x=1724295261; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=gPCANlIQhbsZqCNbnbbPmOo9t3kSZJf75lEGK3ZyGfQ=; b=UCXOknk3VXFcMIdTVZjTU43uKfEXL3WzmvoG7EiHfhZmZcV18+cD5lk+qrHJO1vOPv iTtBErSQkE8kMayGowQ/wVwmE6mEf/IG47t8InuErGJqmSymrjqlJQbkQid5fCStN5pr A1+u8uv7GJ56Vk+B+xtJ29x4pvZOCBaRezEzpZ0BJl/dRRvaiboIVy8NzEsFcy+vRag7 MhZlj6WBQJ57lmiZjplbw9qpl4wVxPwkDT7+mJSaioshAtRRiHhvuLmwsX1gH58P0ED5 ZrsVI3VweOS6eWKprTCNidzGr07MjpCpUmlUgMhPpCfIYBwTk9dAvNwtAWG/5zvx7f/L Zx9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723690461; x=1724295261; h=in-reply-to:content-transfer-encoding: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=gPCANlIQhbsZqCNbnbbPmOo9t3kSZJf75lEGK3ZyGfQ=; b=trlLEv7zNZEpbMSKRT9G+Qf0oRIxqCeR8C9rv0vMqTzH4KnYWExOITR4Tafkqv1+4z 9cfsVvPZpQCFy1Ujx6b41EELDXvBhVWkoT0MIo9+U/OdugQEpnrKdycywZ7BWhh4MATW 1MvImPLstNrAPF6yp7WbGXhFprcPjw2vZoLU31I3UoPm/j3K2VRhlDD+4Xmpn/jNeSda hdW1IcOHRJ3PDcK4ByTWGbGgo4tJkMJQL/2QFuuJeS/MOs1CwqC627BKk7Jn5LlXghja BBzCGd2PqziceoZ6jwzF5NN9FNOJDVIpx9JkSZfOO9bRFevCIYJcjgqMDNfaebwPOyPl Z8Xw== X-Forwarded-Encrypted: i=1; AJvYcCWjHF7+z1pDS01a20H2rPTkAorq6Dvg7S3fGFVUqn9g/spx8yYE1MnY5PJr4MJAhJknm4ts9zb8HYHClOUZbccNaFk= X-Gm-Message-State: AOJu0YxEfF80WRZ5sfjRmVV+w1xv9b/dOxQzqi1l+2YpkbJmpFBFfmLP ySrnt7Jp++kFwK6OalUESeWBfUFTyeIjvT2fnYl1DI1qV6jd9TC5YP8cGfKiYnxM2lrouKUe2fP L X-Google-Smtp-Source: AGHT+IGc2IhX7zyTOdCDZ3pAno7WsNb+k6Dc+VYY9c0J/aKghpebQF37/a9W7U1qlF4/BFzJLfxWaw== X-Received: by 2002:a17:902:ec8c:b0:201:daee:6fae with SMTP id d9443c01a7336-201daee71b6mr37989115ad.48.1723690460698; Wed, 14 Aug 2024 19:54:20 -0700 (PDT) Received: from dread.disaster.area (pa49-181-47-239.pa.nsw.optusnet.com.au. [49.181.47.239]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-201f038d715sm2985055ad.198.2024.08.14.19.54.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Aug 2024 19:54:20 -0700 (PDT) Received: from dave by dread.disaster.area with local (Exim 4.96) (envelope-from ) id 1seQcz-00HV6b-2j; Thu, 15 Aug 2024 12:54:17 +1000 Date: Thu, 15 Aug 2024 12:54:17 +1000 From: Dave Chinner To: Yafang Shao 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 Subject: Re: [PATCH 1/2] mm: Add memalloc_nowait_{save,restore} Message-ID: References: <20240812090525.80299-1-laoar.shao@gmail.com> <20240812090525.80299-2-laoar.shao@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Stat-Signature: 8iyjcesgzjm1bdmpjks65z9irrze4dfn X-Rspamd-Queue-Id: 2A342180003 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1723690461-322706 X-HE-Meta: U2FsdGVkX19HifcK8cheCWFVqnbaa/5u62Jheoc5/n3+wsYEqcnWe6MApgALgz8LEKdOpv2CjbEGDjNAMoz6xicRDUNSd0/gN4yk725oW5BpH2IuMJ2ijp091BngZbvKygKpWktj/5AoP6NJuu6Pe43IDNWfMD5JSmLgY+imRgC1brb91Rmi/WoJMUFbMSFjLCrZQopKsLmBxieUwormmVkHmcqSxsekYnruLE9medE5ba5f9JZaiY2GHgPvlQUPmqMj+0nZJy95exJ+94lJWU0qdjJ7394XUeBuBq7mYXZYO1zy+fq3HONGPffaktL3aasYzpGswrgoPTX2aYFI6aXOtVe55+gZmGD7E/UK4S97RhPeRlZfuvqRr8T+bfUM3wsIQJeCT4Uv4S5rUMHeEKzcoYxpQZCUxt7xccY6Gm9EthYL56DmX2Dc4awX8vbNxcUxwtgPRzXEJJ/eHuY0ZvOVcOK9K/Qil227z+MIcuGKqRR2gzIbwm6tJMcDDiE0Mpsq6WYgy3tZToBIleAP/mj8apgwiLTrqnULEH5Z5QF1DZMZ4Rv2Bnkc2uNi6C6Y8HcxC0l7Gr0wuhZIgR/jyDRQmfSo6k8Aq994Nqv5XNvvmoiHi96KlioYEraqtswfQCcEedZoY5PVWYKOi0+odtYKL73Pyoz5ooerOY8LlBntsBR4FECWMUs+cGEYpt5IhBVqkB0VvLS1uwArBTNODbmucsnaXsDPMkLLDXFjbecCtTHcObP+sbfElJqnfoZ1uvJBQcCO9lKdM69EwxhsYaLRkWctfiox0tbpiCyjvHINVxA2Nfk8TwQKRARtW0IEPFic7hLf+V1XjgZp4zGmoaXJ/SMtzI0sVD2dJTzoo9NGYpKVgPw/vu2WBL35SeS+GdTIFRP7R8OT1nr/NiaR8jq6CGKWHD7p3n/WoL+XPDG8244QLR9jwGHV5pxl/ghsKgYdK0RUKJNA6zcTuem 1tSBcS7l 7UL8ZMcdR7lcAfVPx+tWjR7g9w5n4to2dTgkccRwkxHTmgkYCCsroRYg+a9YITRBH2t44aSHe6K2Wd8vm3CkyjMh9vmhddc0N41qWGGGV3eVHqqr71oyX3x/uULYkGd0YQQnt8G1n/jl0X5sFz6klkdHXzqAmI4CAbomke7GODFMhHp12Bzgr3A5yv07h2KwBh4492YegwV3teblPGOVuF8H0RNfHsLC2mQxpsnVnWn1ikv7Lu3MytTsWCzuELw1xJ9iI7QUS+scJ/FsnqEJCHVgJxXu6XsNHTzR+gqkeG2sCdcmflO7x72MihSdkP8ae0gBJ/YXYFpCBL8V1SOvLRE1FpIY047/2ev4kco+Fg+/OqLmEwiEq6fcBPOilaZN5WbYbWMOvi6uS3lHW/zz65F5zrogeoFsbRrPRwf0Lp60wzjgcZqWpwmUETmEuf6pucnH+AT3wuPQplvrwGhPhljq+CXdfdRstDJcQxzHQ6hyDjhbrxi+cxx1wtf1n2eakmDZ245t70QBiwcrXHpXgVVQER9xhFsOxDSG0 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, Aug 14, 2024 at 03:32:26PM +0800, Yafang Shao wrote: > On Wed, Aug 14, 2024 at 1:42 PM Dave Chinner wrote: > > > > On Wed, Aug 14, 2024 at 10:19:36AM +0800, Yafang Shao wrote: > > > On Wed, Aug 14, 2024 at 8:28 AM 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 complement > > > > > this, let's add two helper functions, memalloc_nowait_{save,restore}, which > > > > > 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? > > > > 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 proposal? > > 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 |= IOCB_NOIO; > } > if (flags & RWF_ATOMIC) { > if (rw_type != WRITE) Yes. > 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. Yes, but only for *some filesystems* in *some configurations*. Readahead allocation behaviour is specifically controlled by the gfp mask set on the mapping by the filesystem at inode instantiation time. i.e. via a call to mapping_set_gfp_mask(). XFS, for one, always clears __GFP_FS from this mask, and several other filesystems set it to GFP_NOFS. Filesystems that do this will not do pageout for a dirty page during memory allocation. Further, memory reclaim can not write dirty pages to a filesystem without a ->writepage implementation. ->writepage is almost completely gone - neither ext4, btrfs or XFS have a ->writepage implementation anymore - with f2fs being the only "major" filesystem with a ->writepage implementation remaining. IOWs, for most readahead cases right now, direct memory reclaim will not issue writeback IO on dirty cached file pages and in the near future that will change to -never-. That means the only IO that direct reclaim will be able to do is for swapping and compaction. Both of these can be prevented simply by setting a GFP_NOIO allocation context. IOWs, in the not-to-distant future we won't have to turn direct reclaim off to prevent IO from and blocking in direct reclaim during readahead - GFP_NOIO context will be all that is necessary for IOCB_NOWAIT readahead. That's why I'm asking if just doing readahead as it stands from RWF_NOWAIT causes any obvious problems. I think we really only need need GFP_NOIO | __GFP_NORETRY allocation context for NOWAIT readahead IO, and that's something we already have a context API for. -Dave. -- Dave Chinner david@fromorbit.com