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 BA622C7618E for ; Fri, 21 Apr 2023 10:23:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3A6BE6B0071; Fri, 21 Apr 2023 06:23:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 356BC6B0072; Fri, 21 Apr 2023 06:23:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 21EF76B0074; Fri, 21 Apr 2023 06:23:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 122BC6B0071 for ; Fri, 21 Apr 2023 06:23:58 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id E5E2014098A for ; Fri, 21 Apr 2023 10:23:57 +0000 (UTC) X-FDA: 80705012514.05.5EBED97 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf10.hostedemail.com (Postfix) with ESMTP id DCA02C0017 for ; Fri, 21 Apr 2023 10:23:55 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=AuJkSwrP; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=otDAQ5ed; spf=pass (imf10.hostedemail.com: domain of jack@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=jack@suse.cz; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1682072636; 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=cO98WjpLnKzbhvXvYHzR4JeJNriOWh1/Af9bFncN/i8=; b=IgA1GeHcdesGgm9yPLvZv2DBYhx2D3d53t78c3u0pxDYie2e5zmz6m3niuChQHzY7PA9L2 Z8pX1XEpk+t3usKMRR5AC0QTA4H2GJGH/llBunpJw0X/MnTvU1taI8Ds1MLsT50N1rX9Sa YwjMA0EDqlYxVOIL4DU6OUsu8F6UJmc= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=AuJkSwrP; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=otDAQ5ed; spf=pass (imf10.hostedemail.com: domain of jack@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=jack@suse.cz; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1682072636; a=rsa-sha256; cv=none; b=4XHp8iVxpY9IiyTgK4Q0PlJbH21Ja+I9s8J5ac7RWSJUiP211LTkoXQAlyTWGLL3CXy7D/ Z9qMY6sAZYXjtfffewuq9WUpdeIoG6rxry5PLZ9MFkxIwucNFtShLxc6rAlg0bKy3Df8h7 162hj22LQE1frEVDU2/sdEL9YOKS1h4= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 7651721A27; Fri, 21 Apr 2023 10:23:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1682072634; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=cO98WjpLnKzbhvXvYHzR4JeJNriOWh1/Af9bFncN/i8=; b=AuJkSwrP90R+MVtx2igqjsiRdCKDM59nlAKKpuS/eUqSRAjSC0Imi0d+EgLbxksW9FnXog Ay1ukngqOGv0ypHAmjWOcFv1Cmf4w4cNrekqGErZkW5ONv2p4Ntpjrp0iSYomHfN2iLifg Kp2rKnAa4AKW9GFRNQHSlC6pT0bz/8Q= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1682072634; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=cO98WjpLnKzbhvXvYHzR4JeJNriOWh1/Af9bFncN/i8=; b=otDAQ5ed1MEY4ABWsMgBA+Rq+33mWUeXLSe4ioruzGgwkVg7AN/+yHTaOlBgY133KaGU8r 9zDTMd6ZvfeJhRBA== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 61E201390E; Fri, 21 Apr 2023 10:23:54 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id yeTcFzpkQmTtbQAAMHmgww (envelope-from ); Fri, 21 Apr 2023 10:23:54 +0000 Received: by quack3.suse.cz (Postfix, from userid 1000) id E0F91A0729; Fri, 21 Apr 2023 12:23:53 +0200 (CEST) Date: Fri, 21 Apr 2023 12:23:53 +0200 From: Jan Kara To: Jeff Layton Cc: Christian Brauner , Alexander Viro , "Darrick J. Wong" , Hugh Dickins , Andrew Morton , Dave Chinner , Chuck Lever , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-mm@kvack.org, linux-nfs@vger.kernel.org Subject: Re: [RFC PATCH 1/3][RESEND] fs: add infrastructure for opportunistic high-res ctime/mtime updates Message-ID: <20230421102353.blzqjrglgyiupf3g@quack3> References: <20230411143702.64495-1-jlayton@kernel.org> <20230411143702.64495-2-jlayton@kernel.org> <20230411-unwesen-prunk-cb7de3cc6cc8@brauner> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: DCA02C0017 X-Stat-Signature: 3gwku5yqi8dxy3y6t94iqk9xdg9b8xcf X-HE-Tag: 1682072635-295770 X-HE-Meta: U2FsdGVkX1+9ciLtsY5Qb5dXsFzj+5vbsUqCKij0QpxwacFdYN0IxQwTVRx6uxRBt19MmrmYBvkMnYZ4yG6Ddhx1oXS4r7JJRuE2RqdiUuZz6RSIQTSgLwwwGd91/exmQsFFvFe3m2Zw6cDlvNQco8/6lW11Tec2oTM6zzywYsKnNEJ0ZaOwehMt5bFdej9YyQWtU72gfppUejBOnFPQVENlfgvNvIJwXSsPAKoIzOY7YSSto09T8+gwde9lc9kSoyvT85nbA9kPEWRKR6HBH2Hf55HsGgCfPQCWRhsIjOgOgfjmSDWyddCSl4YsYeTcA98mrZI1rOvYw5mqPtxDXqlhtVXEWK+h/X4WUZYDZgnVgLQctZWTJVJy4lbnJATzvQNvDSrkNhEa/L1NDj92xMJYNjd4+OZgCwdHV29WflMO0f9f8u4snMtJE4/FrmTW+wbLbAlDnhqPqjAUqYZQsEbiSqAw+n5ES7Ba4UX8XBs+slnygFyN6hO6NAkO222vTG/p7QYv2L3ml3LgOmh/eivim1JkoPpladUF/kKoNIhu6dA2x+j3xgPG77NKy4Cpkc7DG4wK0UQfOyI3KLvjINSFOvHAPT/ScLHvnb2/Pnwf/MaFxYVK1NJM5JKD4Brbghhw/Y6TfwkjbRc2sCgbkHmo6gFQxBVNSMmIkOvg/vchc43mVxbGULh8s8/ZbErS/BNZF3uYE5RSdbx2bs65sqr8qqxjVIU+TVG/Dgr6KIuBb1X23wqnBKBsH1YHhXomkRoHby5JklLlAJ4FUrrEGMpRDC3LZVN/kK4FquX2sgCRcGJMKC0WmhnWSpj7as5b5HCJU9gGbSEQJ/YWuE+Ji/4kPpQLjxg/cjpPBo5QM+QaiTKWxwuZb71eXIO+hz7Pfh8mfvxP5DAFAwuQZxIsCNQd/cnAmEflFJ8ndYh8d6R7OFYkHqPF7HIhR86cmbw/154VTLkHuBy0iqsGHSq EzWLHYsu 1gsHkNNDGbLVPFrlQeGbCbVU9gGGo1DZhyazi434Uw7obK9LSnNFIYexXsczZ7l9k796fvEA5JV9xmBYqthqN4I0U6P1ZOqsQi0KMfGFj/nBhpLWSta7DWjqh6mmW/IVPum/R5UNYNERG6O823CJ93H+Vsj0ZUICUS6Lv3vHA/F73IWg5SjfiLQ7/L2cfPmCymURJM2e83YSTioQgD3PMx11VwyPWvXNyrUSZgwrRbqxoYzJZF16oofDPbvFBYMIvOzhF 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 Tue 11-04-23 12:04:36, Jeff Layton wrote: > On Tue, 2023-04-11 at 17:07 +0200, Christian Brauner wrote: > > On Tue, Apr 11, 2023 at 10:37:00AM -0400, Jeff Layton wrote: > > There's some performance concerns here. Calling > > stat() is super common and it would potentially make the next iop more > > expensive. Recursively changing ownership in the container use-case come > > to mind which are already expensive. > > stat() is common, but not generally as common as write calls are. I > expect that we'll get somewhat similar results tochanged i_version over > to use a similar QUERIED flag. > > The i_version field was originally very expensive and required metadata > updates on every write. After making that change, we got the same > performance back in most tests that we got without the i_version field > being enabled at all. Basically, this just means we'll end up logging an > extra journal transaction on some writes that follow a stat() call, > which turns out to be line noise for most workloads. > > I do agree that performance is a concern here though. We'll need to > benchmark this somehow. So for stat-intensive read-only workloads the additional inode_lock locking during stat may be noticeable. I suppose a stress test stating the same file in a loop from all CPUs the machine has will certainly notice :) But that's just an unrealistic worst case. We could check whether the QUERIED flag is already set and if yes, skip the locking. That should fix the read-only workload case. We just have to think whether there would not be some unpleasant races created. Honza -- Jan Kara SUSE Labs, CR