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 57AC4C7619A for ; Sat, 15 Apr 2023 11:35:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 90A696B0072; Sat, 15 Apr 2023 07:35:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 893556B0075; Sat, 15 Apr 2023 07:35:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 75ABB6B0078; Sat, 15 Apr 2023 07:35:37 -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 6015F6B0072 for ; Sat, 15 Apr 2023 07:35:37 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 2B2A9AB367 for ; Sat, 15 Apr 2023 11:35:37 +0000 (UTC) X-FDA: 80683420314.03.3E93DDE Received: from mail-vs1-f51.google.com (mail-vs1-f51.google.com [209.85.217.51]) by imf10.hostedemail.com (Postfix) with ESMTP id 70D49C0005 for ; Sat, 15 Apr 2023 11:35:35 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=hT8wjsnN; spf=pass (imf10.hostedemail.com: domain of amir73il@gmail.com designates 209.85.217.51 as permitted sender) smtp.mailfrom=amir73il@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=1681558535; 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=ZQuUOaQjNnI3LhQDwWrlJuNdVQ2r+6got/EIYQa54mo=; b=eyvSIxnJs6v01ed62KRmvMasAbhKhGIpXAxohwyJ0w6ZgDsKHix4dTLDjXo9NbYidSijE5 IroyS+0c6ShNeoOwIjkVvquL28/AHgYwNWs8eLN1kLIYaUW6Se5shOFmkw0Q34asapp/8o Xvq3Zfxj6+MWD+BDRQ/lPHvj8+mDX2Y= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=hT8wjsnN; spf=pass (imf10.hostedemail.com: domain of amir73il@gmail.com designates 209.85.217.51 as permitted sender) smtp.mailfrom=amir73il@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1681558535; a=rsa-sha256; cv=none; b=5t9Q3LpS1geB591fI2F87ZbFJnsnwYiKZ20OsyGCaxf17RUkvYfPzdU1EtwFzpfQjWBFqm oTrQcwWtGYpDZ1YSiwoIgGEt2/jqdiQRfpl86Feoqjc10RzB6u+jYxGm9yg2jmF5IgtQqN AT+3JE3DamIDYWGAMEVmUXz0RzoQj90= Received: by mail-vs1-f51.google.com with SMTP id y13so19219437vss.0 for ; Sat, 15 Apr 2023 04:35:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681558534; x=1684150534; 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=ZQuUOaQjNnI3LhQDwWrlJuNdVQ2r+6got/EIYQa54mo=; b=hT8wjsnNTBtxNV9WKobkwO35hvbv+s93dkHMP++9f/1/yX96veY5u3ERIYT2T46NVk KszWwLe9zlujxutksbHT6u2NeQBjlwdwLFftNaWqnjqjD1G6zgxNDZGv8ZJNX2oNgN8i fT4HiGQiWIp0HZCXFnwKxN7+dfVSymYT3G8vggYn0UKwtU+DhbzPdgBP95gt4HGW9aBM ZTBFHjRIY5BqF2DubsYiASXywhfP4L2sjB8g5o0YTDGt0W6mi1SBXPvv4+8/6lCGorOp fhHMxv53wlfXEg/Kx7BN1S6K7+m8BwqYCQs11r0H+CdrBx2zz2z62OZi22t5QslJRQdY JfTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681558534; x=1684150534; 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=ZQuUOaQjNnI3LhQDwWrlJuNdVQ2r+6got/EIYQa54mo=; b=BgIond8LUbpHQ1JrNlaK/CD9fD3rNd9XajvfsKto+On0yxbu5/RR9HHZ2MReui0S4r Lq140g8gnFjSPzkHT+EWPFiDPXJC5KZOSvXjrSIlNvIup+zATpznnxF9Knvh5c8k009T o2B7bPpFwef8bOARePwYaKtRqCuev6RpFeaBmuvUkPgDA+QI0Au3Sot6n+Pp2BXiDqkd MhasVLFmKWUqv1iBYq5lMaYaFsr/KOOkZz9sFrnpQQnc4bLo4TH1VkeWQynt7K2H71s0 n6APst1Ef/7tr0dMjutcO1t7cVsy7Jlhcocz2mnDGzc07cvv4y7CZm1lFGUqOjN8twrm w62w== X-Gm-Message-State: AAQBX9foSn/T7eUscRlC8WKbAj+IOL+iAQKoj8cxhzV45sIzxd8njxCA D1cpctyZ+qHCf84oKpiBoYpVYCscqojitWl05aE= X-Google-Smtp-Source: AKy350Za/ZW99Sc2eyyPRafhDAV9O3OPsz4ldcuWs1DITk9ZzkGG9vMclYoTfMfN65WHNKYQ3O0J3rDvritmjvle96g= X-Received: by 2002:a67:e04f:0:b0:42c:48e9:4fe0 with SMTP id n15-20020a67e04f000000b0042c48e94fe0mr4869637vsl.0.1681558534297; Sat, 15 Apr 2023 04:35:34 -0700 (PDT) MIME-Version: 1.0 References: <20230411143702.64495-1-jlayton@kernel.org> In-Reply-To: <20230411143702.64495-1-jlayton@kernel.org> From: Amir Goldstein Date: Sat, 15 Apr 2023 14:35:23 +0300 Message-ID: Subject: Re: [RFC PATCH 0/3][RESEND] fs: opportunistic high-res file timestamps To: Jeff Layton , Dave Chinner Cc: Alexander Viro , Christian Brauner , "Darrick J. Wong" , Hugh Dickins , Andrew Morton , 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, Josef Bacik Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 70D49C0005 X-Stat-Signature: e93r8x38zhx7eenqdm9thghd4rh4ub8y X-Rspam-User: X-HE-Tag: 1681558535-300673 X-HE-Meta: U2FsdGVkX1/zHyiPk746C44172IS4c5TDxRuMjh0xLfG6pgK/SlzFYStswKdqFIW4Exnmg23JHY2+Hr0nk7RtlT76x8KnkLNZ5mIcfeRGxLEC1ReQx3/v8CAXiy+ebpS1NJeUuiUrMbSF9fL7w0ugW1gNuENRz3rkaRbqDOqwzgwfEairlKPdGHNcWXMURmihSVSe9Z6aq++x9ikmw1ytdIGUDUmEdY2NDM3evDxCIrgbcGm5oWyZ5c4xp4FTDDCMKZiUMb4BP4sL/hk1+Qi9ukadgCC+cQ/uHpNjAWP6EYadkJx6MsYDl6Nocwgu0jkdUvfoOlrRSF9F/Au4zO9rp364FgIBHlWT/DXttgRkpdqtOT/oGLqFHm4bwvPk3zPhy3n+7MVrNi8RJF9bCK9MKnV2qKnzuiAVMQEksHYcCjyEDfd8yBPn2cSuvmXyBkbF9Pe9W4HzSypdkqUsQvcfh+63EDYvPqvAs69ob4Ims6NnSmKBPU1br9cmShVsVS/YPB21idp1a5a6Qxgg7O+tcpQ6AqoYEgPA0WqBwV7ISRuIwXFVUB6MF9HqYXoG9OXSNidRSjsPeePbvTSX7WscKlk60a1bxbBh9r7OPT5u4PHKZpOcrtZYlVyJEgcCug3z76nch0ugSp6M8IY1mKIoOcF0f5/SAIYlmrRyx+opGINwfLIj3hmT7mG9DgkaNNifsT7MxY6EPjSjOZL/5Pn67YKInnWqzIOHndp+T+hMqF/fWpmWQj/9FRhjky7g5MZEzgbQNQPlj8ej/QukoNbFhH+3/rY/oOYWBIdbTt7VCB/p613Ft6L4UH+I4CLZrcwPEVlHWHSl+/PyreECua9y4KU6MJqF2H8plRmI48AVvLFTSWNmPH03pV6Ky/USXm5Uw4nhfxXa/g+sOd1QO17kXXhB7YgntRZfI93YFQieO0HLprSwc2VkWfe5jlQrrYLP+xjYP+Htaw/at72Ez9 ZdDGoIwm k+LAqF1yBgu5xK0Er4BfWcm7DUziuIGubWegFEUqpUmyJ8xbZn8mjIH+weH6XvcbtooBI6w2BqOTi6NFP3VMzmYzDlWxhoI5c/6XOofD8A/NhMcWpw8yoICft65GsiM2+xd5tmT5Fm/Mim9U9CtJ08kbF0o+CrGHvu8d0jDH/o6OS+rL0E6y0NvtzGhbsm/WpHBCwU5DFpQzaL9HZ20hlNsrYiPAwqe4AJSuFLrAPrSm/ZlpDuL46ZslSYCuLqWgpwux/scD9ZSkUJlWiDhCIY9d0KYQ+/U3hV4A8sFSERqp2orBRIy4aetjOGlrforaw/8PG8FnKp6qIKEcqGbvJEKiCc/Hg8ZalSKQgnwUSHVIujxdtE3FayGCnJwnzGqjWpr6YZOY5EVgC9O264FOEMWZWLiG4HKMy0VpD 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, Apr 11, 2023 at 5:38=E2=80=AFPM Jeff Layton wr= ote: > > (Apologies for the resend, but I didn't send this with a wide enough > distribution list originally). > > A few weeks ago, during one of the discussions around i_version, Dave > Chinner wrote this: > > "You've missed the part where I suggested lifting the "nfsd sampled > i_version" state into an inode state flag rather than hiding it in > the i_version field. At that point, we could optimise away the > secondary ctime updates just like you are proposing we do with the > i_version updates. Further, we could also use that state it to > decide whether we need to use high resolution timestamps when > recording ctime updates - if the nfsd has not sampled the > ctime/i_version, we don't need high res timestamps to be recorded > for ctime...." > > While I don't think we can practically optimize away ctime updates > like we do with i_version, I do like the idea of using this scheme to > indicate when we need to use a high-res timestamp. > > This patchset is a first stab at a scheme to do this. It declares a new > i_state flag for this purpose and adds two new vfs-layer functions to > implement conditional high-res timestamp fetching. It then converts both > tmpfs and xfs to use it. > > This seems to behave fine under xfstests, but I haven't yet done > any performance testing with it. I wouldn't expect it to create huge > regressions though since we're only grabbing high res timestamps after > each query. > > I like this scheme because we can potentially convert any filesystem to > use it. No special storage requirements like with i_version field. I > think it'd potentially improve NFS cache coherency with a whole swath of > exportable filesystems, and helps out NFSv3 too. > > This is really just a proof-of-concept. There are a number of things we > could change: > > 1/ We could use the top bit in the tv_sec field as the flag. That'd give > us different flags for ctime and mtime. We also wouldn't need to use > a spinlock. > > 2/ We could probably optimize away the high-res timestamp fetch in more > cases. Basically, always do a coarse-grained ts fetch and only fetch > the high-res ts when the QUERIED flag is set and the existing time > hasn't changed. > > If this approach looks reasonable, I'll plan to start working on > converting more filesystems. > > One thing I'm not clear on is how widely available high res timestamps > are. Is this something we need to gate on particular CONFIG_* options? > > Thoughts? Jeff, Considering that this proposal is pretty uncontroversial, do you still want to discuss/lead a session on i_version changes in LSF/MM? I noticed that Chuck listed "timespamt resolution and i_version" as part of his NFSD BoF topic proposal [1], but I do not think all of these topics can fit in one 30 minute session. Dave, I would like to use this opportunity to invite you and any developers that are involved in fs development and not going to attend LSF/MM in-person, to join LSF/MM virtually for some sessions that you may be interested in. See this lore query [2] for TOPICs proposed this year. You can let me know privately which sessions you are interested in attending and your time zone and I will do my best to schedule those sessions in time slots that would be more convenient for your time zone. Obviously, I am referring to FS track sessions. Cross track sessions are going to be harder to accommodate, but I can try. Thanks, Amir. [1] https://lore.kernel.org/linux-fsdevel/FF0202C3-7500-4BB3-914B-DBAA3E0EA= 3D7@oracle.com/ [2] https://lore.kernel.org/linux-fsdevel/?q=3DLSF+TOPIC+-re+d%3A4.months.a= go..