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 82931EE49A4 for ; Sun, 10 Sep 2023 22:01:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 920CC6B0150; Sun, 10 Sep 2023 18:01:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8D0CE6B0152; Sun, 10 Sep 2023 18:01:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 771816B0153; Sun, 10 Sep 2023 18:01:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 647516B0150 for ; Sun, 10 Sep 2023 18:01:31 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 13483A0807 for ; Sun, 10 Sep 2023 22:01:31 +0000 (UTC) X-FDA: 81222059982.16.8BE20B7 Received: from mail-pf1-f178.google.com (mail-pf1-f178.google.com [209.85.210.178]) by imf06.hostedemail.com (Postfix) with ESMTP id 2216C18002C for ; Sun, 10 Sep 2023 22:01:28 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=S5SetieR; spf=pass (imf06.hostedemail.com: domain of david@fromorbit.com designates 209.85.210.178 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=1694383289; 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=EyybjuBSw2AsBAibBPVqGccWs6P0JtTeGBB0Kwx90Dw=; b=TaHpUOzPfmip1yZYVQ787L1Pt/R7xjhpdn9daJnN8MngA+We6UPT2dl+vSMRZUk6Ty4GL+ YqWwImjjqzXGcgOwBlkKD95nw9yyUCD6Z1eUJ51RAUQmHKkIVf+EH4Pt0TAw+uDstGAQeL G2IHOGw9pLVoShbVJVDuj0ZHpJVFbrc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694383289; a=rsa-sha256; cv=none; b=BeIzpwjOVqcuyZ+D1JloXVgfnLoPkeZfxk7tedYxdfL3BRDomKQSGInRvDwKK8ryDEL7ip F2Z7Bye6Q2MsO7UwgojcMocCpA8UrjSvM322SGC5SaR6MFOx3D7rnsXA+xNy0SFMsCkfGW Ko2GqCphxfYQTNF49N6so8xwxL9yI+4= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=S5SetieR; spf=pass (imf06.hostedemail.com: domain of david@fromorbit.com designates 209.85.210.178 as permitted sender) smtp.mailfrom=david@fromorbit.com; dmarc=pass (policy=quarantine) header.from=fromorbit.com Received: by mail-pf1-f178.google.com with SMTP id d2e1a72fcca58-68fb6fd2836so844477b3a.0 for ; Sun, 10 Sep 2023 15:01:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20230601.gappssmtp.com; s=20230601; t=1694383288; x=1694988088; 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=EyybjuBSw2AsBAibBPVqGccWs6P0JtTeGBB0Kwx90Dw=; b=S5SetieRE1JdgAd1Z+56mseNzTNXApRkb0NfJ29AmMsfjElLE+3LLUI5gRfiwP1445 G1LIRYCeAmlEkXNAl+ErhKvhqV2LK7MjcLGBJ8CsZ7Txcy0Bq+iS5OWjQus7I2wpJVyn 0AVj+TSSXej/hokziCWH6mZ5nDDgCw4T9SbUF1VeKwKQyrj1GdkV/nMus6upBuixwkQo BKiWnaTfrzeHeQsDWuZq/so8IH8PzfRbatXCD/DEAW9Ftt0QyGCCrmhGRtphLQDDJXSA AzW2KaD5wooaaI+/Lbb7KZfy4oNNOf1nFy2gZeqc7KOlw0l0FPl28okCN6vvoASVX0RR nKJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694383288; x=1694988088; 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=EyybjuBSw2AsBAibBPVqGccWs6P0JtTeGBB0Kwx90Dw=; b=jHnkfMFe07tNc90rPghAORYp7vYxnwuRWe6aShBcmNOm7zFV9gwEY17C5fmTWbHHLX 55ZzogSb6hQ8Tz6IsuSDIARDR8NLekeP68lYP7tu8zayhfKMz8oypjbmzPv18OjQ0M+X D+yZoGdTf+q6HN0fWmndYYKOPwDigTiIFA1qrlzQvYLDFggGb5ZXg+YNW46tDEkRVUu4 f2lVse8OuZlSywhPsqslZKzXhn0zXb+CJO7vFN8lf2pmcPIMnwpUF6FxR/P2uoRiD+Yp VVukXvfCbmZnAHLs0OvP1DlGuDXu0p+7G/VkHTODgfQsqU3QhrM2CIgeaLnwSYHb5XXE P2ng== X-Gm-Message-State: AOJu0YwHeiZhbUB5NdVQqsM5zGU3mxAi7H94DDQ1g4v1ri/F7KE9ZFxm 5BY5fbfoFY0Iajejd3V5zNQH8A== X-Google-Smtp-Source: AGHT+IHSYFPf3w2qdTZr9bikkzuSsvPYQjYYZyW+Zfc616rQWXs3Eeo2BzwinmhhOfJVOtnHj1lBTA== X-Received: by 2002:a05:6a00:1a0c:b0:68c:57c7:1eb0 with SMTP id g12-20020a056a001a0c00b0068c57c71eb0mr9371853pfv.11.1694383287795; Sun, 10 Sep 2023 15:01:27 -0700 (PDT) Received: from dread.disaster.area (pa49-195-66-88.pa.nsw.optusnet.com.au. [49.195.66.88]) by smtp.gmail.com with ESMTPSA id u10-20020a62ed0a000000b0068a3dd6c1dasm4403641pfh.142.2023.09.10.15.01.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 10 Sep 2023 15:01:27 -0700 (PDT) Received: from dave by dread.disaster.area with local (Exim 4.96) (envelope-from ) id 1qfSUe-00DWBA-0u; Mon, 11 Sep 2023 08:01:24 +1000 Date: Mon, 11 Sep 2023 08:01:24 +1000 From: Dave Chinner To: Pavel Begunkov Cc: Hao Xu , Matthew Wilcox , io-uring@vger.kernel.org, Jens Axboe , Dominique Martinet , Christian Brauner , Alexander Viro , Stefan Roesch , Clay Harris , "Darrick J . Wong" , linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-ext4@vger.kernel.org, linux-cachefs@redhat.com, ecryptfs@vger.kernel.org, linux-nfs@vger.kernel.org, linux-unionfs@vger.kernel.org, bpf@vger.kernel.org, netdev@vger.kernel.org, linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org, linux-block@vger.kernel.org, linux-btrfs@vger.kernel.org, codalist@coda.cs.cmu.edu, linux-f2fs-devel@lists.sourceforge.net, cluster-devel@redhat.com, linux-mm@kvack.org, linux-nilfs@vger.kernel.org, devel@lists.orangefs.org, linux-cifs@vger.kernel.org, samba-technical@lists.samba.org, linux-mtd@lists.infradead.org, Wanpeng Li Subject: Re: [PATCH 07/11] vfs: add nowait parameter for file_accessed() Message-ID: References: <20230827132835.1373581-1-hao.xu@linux.dev> <20230827132835.1373581-8-hao.xu@linux.dev> <642de4e6-801d-fcad-a7ce-bfc6dec3b6e5@linux.dev> <6489b8cb-7d54-1e29-f192-a3449ed87fa1@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6489b8cb-7d54-1e29-f192-a3449ed87fa1@gmail.com> X-Rspamd-Queue-Id: 2216C18002C X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: t3xadytwdexfb8dsjx4bwrdmwdx5o8un X-HE-Tag: 1694383288-793880 X-HE-Meta: U2FsdGVkX1+5NKS4Rr911H0MjqBDJM96naRdmC2hO3HoQb665DvTDM2R0RgvHR/Z2LZOA1KwlWbH3TUo3szfUDGtghnBOT/NEkqPLcEAHe0DpP/r36IIAJSJf4v0OlIuwStzcKuKt2ZUVOHfcjIdWUobI2huXhC24KmCGEqUN1xv1DoEqkY3u5oovzHpW4P1+kWOzvB3LvjYgWc2au83e//VZER/GyHN/+lJgoCpdVGczWuFCCW+NZhgnuy9Zxm5pMuC/6rfnA4MK0oVRzc1WPtkFWfsrW5kXyP+l0/dYsHULtq+cBqIZzKeWEiF7rrr8UssErX4kOfDdUgeHKw1/8nqmTfmsj0+/N0X5g6jepPFf97M6FwQvMIUvHlLJVbEOl9Cpo45oCU5mq+nN2dWmB7zq0JIejE1Bk1Or8CEKqk7yB60oTZ8V2jFaoiDyk5wuak0bWFdgpOKqfl4DHQ/plTohBiVwLVpC89+jfE24or/21uXE241izzmwq2L3uXA2ByNBUwAnu3ZG2XyZV/O4rGw1k75WKK9sF8P6+5QMGfFjYcsL3s1uktX+RWA1E393Hc8VV9l/cHDsP9IT2qdSrox6vcK7v6K7G8SozTZBYKgxzJ1gPC1GwoL6cmLanSIm9MtltnViSDfwk633hZqG0X/cy0ffnqawlICfnW6fm+wpfVYH6l0ENucvNGJ/CT7Q/3ovQPW6YvBK2ZCFuZ+6FiQ93GBmYMxVJQ8fSNkMrj7IGgRgCShWm/VMCRqfYCpgDQ9VNj1g9aeoJY6hdcnFxVj95wc3jkXEMCCarXFaxPwKHtgeE6Yn/zYDU+Rd9bGZGG0wNIv0LDNP3qYR5WYr2HKRtzoNJS7EYPiTNspWKoY50m3D+AZMMDObK3ceeCdgWLBospNm1W2FlBzoD4kstO/Y6EANYsxklm7Ox9hUvbTzQcfLQWDF7h27ETC3LlPiwT2apGGNgNCPFeLoLE 8X//5Zbz 9Ihg5vagRuBmR0g3FPQZfFpxuEDGKBrIYDgH67uLZaV2ek4rzz9wlPoeNCC/q2ZDlW2FC126qX4mHpBOXfDDvWAGRvS0QGfJu9vjdO65CkHuirpSQZK30pVUmdLp+YtzzioO6YtyLIuACITnAnQFnyqrzltxTbmmURU4o9KuXjQrlfw8VBObV91K+LSWTT+rxrHqNxdkLqz/tRfe1LpXaGGZnq53yfFsBJJQyV03otGjMXdTSmJWkAm4wU7u1TchuD/mASamKwfV7js9WSvPRsxVrJb4oCtmOj7O+RUXd6MzocxSm9DQW1tqTUDOw2SdzQOiUZKDFkzwt6yO5rCImaEYUI9tsogqWelUS46oQqIdThR9wc0qQ7o3hSLSe1ztW/qP/EiA4LVaNSA00Y6BphdN7JEdVPpysO8hV1EshoIZNlaTdsRBVY2TDEwiO1aArFcZq4ZDR/6KwrK9yZyp9Rr9K3SHURUtNxgMNCX94xcDgs2z6uMcYGvmvjsNXzahZpWEprsBNul0qqKKQrNWUBqkde5jZrf8darGG1i8cntGCQvwffRZVcKJcGOlHiwcBMBhckXLYRQd11fwtBjhJk/AyhLOKULQf4gS17RiueKFLU5/TAOEmSP805dTAcfG7fg7NCpo3nMBH9zGLZJEOiPvINRXGwX9FXNhUHaVTEwTW737GM2GxzIPC7+40QDscqydqJ72Jpcce0Nw= 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: On Fri, Sep 08, 2023 at 01:29:55AM +0100, Pavel Begunkov wrote: > On 9/3/23 23:30, Dave Chinner wrote: > > On Wed, Aug 30, 2023 at 02:11:31PM +0800, Hao Xu wrote: > > > On 8/29/23 19:53, Matthew Wilcox wrote: > > > > On Tue, Aug 29, 2023 at 03:46:13PM +0800, Hao Xu wrote: > > > > > On 8/28/23 05:32, Matthew Wilcox wrote: > > > > > > On Sun, Aug 27, 2023 at 09:28:31PM +0800, Hao Xu wrote: > > > > > > > From: Hao Xu > > > > > > > > > > > > > > Add a boolean parameter for file_accessed() to support nowait semantics. > > > > > > > Currently it is true only with io_uring as its initial caller. > > > > > > > > > > > > So why do we need to do this as part of this series? Apparently it > > > > > > hasn't caused any problems for filemap_read(). > > > > > > > > > > > > > > > > We need this parameter to indicate if nowait semantics should be enforced in > > > > > touch_atime(), There are locks and maybe IOs in it. > > > > > > > > That's not my point. We currently call file_accessed() and > > > > touch_atime() for nowait reads and nowait writes. You haven't done > > > > anything to fix those. > > > > > > > > I suspect you can trim this patchset down significantly by avoiding > > > > fixing the file_accessed() problem. And then come back with a later > > > > patchset that fixes it for all nowait i/o. Or do a separate prep series > > > > > > I'm ok to do that. > > > > > > > first that fixes it for the existing nowait users, and then a second > > > > series to do all the directory stuff. > > > > > > > > I'd do the first thing. Just ignore the problem. Directory atime > > > > updates cause I/O so rarely that you can afford to ignore it. Almost > > > > everyone uses relatime or nodiratime. > > > > > > Hi Matthew, > > > The previous discussion shows this does cause issues in real > > > producations: https://lore.kernel.org/io-uring/2785f009-2ebb-028d-8250-d5f3a30510f0@gmail.com/#:~:text=fwiw%2C%20we%27ve%20just%20recently%20had%20similar%20problems%20with%20io_uring%20read/write > > > > > > > Then separate it out into it's own patch set so we can have a > > discussion on the merits of requiring using noatime, relatime or > > lazytime for really latency sensitive IO applications. Changing code > > is not always the right solution... > > Separation sounds reasonable, but it can hardly be said that only > latency sensitive apps would care about >1s nowait/async submission > delays. Presumably, btrfs can improve on that, but it still looks > like it's perfectly legit for filesystems do heavy stuff in > timestamping like waiting for IO. Right? Yes, it is, no-one is denying that. And some filesystems are worse than others, but none of that means it has to be fixed so getdents can be converted to NOWAIT semantics. ie. this patchset is about the getdents NOWAIT machinery, and fiddling around with timestamps has much, much wider scope than just NOWAIT getdents machinery. We'll have this discussion about NOWAIT timestamp updates when a RFC is proposed to address the wider problem of how timestamp updates should behave in NOWAIT context. -Dave. -- Dave Chinner david@fromorbit.com