From patchwork Thu Jul 26 13:07:52 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Arnd Bergmann X-Patchwork-Id: 142966 Delivered-To: patch@linaro.org Received: by 2002:a2e:9754:0:0:0:0:0 with SMTP id f20-v6csp439940ljj; Thu, 26 Jul 2018 06:09:01 -0700 (PDT) X-Google-Smtp-Source: AAOMgpeqBIVKOQeqzxafl/wSBSj21ctFxnaq169thQMoRO1leYqFghXQeRigejaOkhNfRnXMPMTX X-Received: by 2002:a63:f449:: with SMTP id p9-v6mr1938474pgk.213.1532610541597; Thu, 26 Jul 2018 06:09:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532610541; cv=none; d=google.com; s=arc-20160816; b=rwnb9b1dQDxVm5K4GhoOsgQ3n5Mc61u/L85kXeIBBUlx/BpOE5axf7x1KRyaASNUP8 qdbeXQ5qLfdbsVOz0A0Lea1HtCrZH/f/yApw1bs7yl0/HwdZnpJmt93o7jz5fVPyy2bx O+FKrOk5KutNoXMTNtYjwZdpJewXxqDH7PrT+QxZ7+aJCoQ+A/86RbX0ugyKaj+Rk6L7 rViAVybE9n9ZG9b3JaG7lYgKCeAhBYnTURVido5jZhwH6dQPbkD6yEX88eVAMXSOq3iK UCdkrUDa5MtnV0vUGjTqnDPzVQ1VjFTVYTGz93F0C/7TB3KECTL086gISgDem7pzYIBw x3QQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :arc-authentication-results; bh=JbrzlmfGCJvKl/5QcjU2VKO4RN7PD0Lq+/IX5bkvyNw=; b=fkNmRevj6Fe70IG5MC2M6tvDGcfTCfamxUpbgVHxtT6Y93wSnOcKV3IfvcP1Z5C/F+ Sm0gMhXs4hNVbdTXoYRje9aD7++Jfb9PPqqNJBFVPiGzJd66Q81jFv/8T4mygg2h/UQO 56bzRnY+4/yqzcAcHbbBGeke/X1KluRsKg6ilqPb0MeSlCKWRe/mX2o4nJcsVB2f5yGu 3ZWXsD1ijJ+FNBUV/MZXg9gpNQi5PlDcQ6tNzuYbTRc8SOla/eFtuxIjRVQWrTeg+Hs0 CtibwR6hDhrHR8NalargODUJzjwvCNTJb/DpLrxvsX0z10PdGpp0DIHoL7P9psKlXn4R V6Xw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h13-v6si1228389pgr.338.2018.07.26.06.09.01; Thu, 26 Jul 2018 06:09:01 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730179AbeGZOZq (ORCPT + 31 others); Thu, 26 Jul 2018 10:25:46 -0400 Received: from mout.kundenserver.de ([212.227.126.131]:42318 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729873AbeGZOZq (ORCPT ); Thu, 26 Jul 2018 10:25:46 -0400 Received: from wuerfel.lan ([109.193.40.16]) by mrelayeu.kundenserver.de (mreue001 [212.227.15.129]) with ESMTPA (Nemesis) id 0M1eUE-1fyQOx2mjq-00tmbJ; Thu, 26 Jul 2018 15:08:25 +0200 From: Arnd Bergmann To: Andrew Morton , Alexander Viro Cc: y2038@lists.linaro.org, Dave Chinner , Andi Kleen , linux-fsdevel@vger.kernel.org, Arnd Bergmann , "Darrick J. Wong" , Jeff Layton , Miklos Szeredi , Jan Kara , Matthew Wilcox , Deepa Dinamani , linux-kernel@vger.kernel.org Subject: [PATCH] vfs: replace current_kernel_time64 with ktime equivalent Date: Thu, 26 Jul 2018 15:07:52 +0200 Message-Id: <20180726130820.4174359-1-arnd@arndb.de> X-Mailer: git-send-email 2.18.0 X-Provags-ID: V03:K1:5toE5J2olpJaV8tZ8hZvsmkv7pAgQzfGT0uRkDZ/AYsBpI0nl+G MVV467y6QbTUQSe8Nng63vil9PKl8lvDgvqCe+iDLO8Xbc1YZp/JxEPigFNQbcDELMp6uUH bt1Fw/vRcdWdU3OqggZQJuK/SHGfW0t09GEbbyPCdAY4hjklVfJZNXfXPQiLDPOjG6xlXty ajPCYBkse1VAHAc0sPJ/g== X-UI-Out-Filterresults: notjunk:1; V01:K0:tOy3X5Oqi+g=:DVMPN97+/DbMiOBCUFjvk7 vtsRhVzXnR+UWwMe4EjIIGFvi0ewDIwcc0rdjI/FIemE2Ft2Uazo5Xb148y/VvQK7FtvzpIkN MWVmTn2Wswp+33gUr6sOdiKSSwty6E4pwekQ4hLH5R8xXUtTnQic8cTJSTOnYZ95QGEQi+fMi XFhBhDyA1T6ga/gtJaDcsT5IRnr8Auli4xIB8T8bpA1TKOE3SFNfDB8cLoIvz0uahITV5Ap+a oar8RtWBTwrxNtmeolnw4oTVvjoOH0iphzW1eqNFXxtEqxBqVr+1psVHuHgnp9qnoS+erICUj tdNVPEIi55ivnrQ6LcsFix4P8yMFT4oIb41W6FOOqBi/bldqXMDT6ErmYPcQN/U17ZJOceVPn b5OcKMCGh9ewXyH7JsBgEUu7KcdUEdp6/vjw2+txoYEJQuw75qYrR8bEeOsaVPmmgnkKU99JQ zrqHT+PxwOogm5LvRWX3Hk9accJiYpcd2p9rqQTwcEoUyrsSqJQIB0+uAvtd8Drpd2f2bbS2t c4ScJ0lmxfgD53L5RIpYBXS4yxtPRuZAkAqwUtEFcVpUw6AI4lHvT7EvEJJHC6lGFX8VaIW02 GtIMe7ZJL8ubeXi1VIJ5u1o+sHbSqt+eeNzJKz0a+mv02rAEvHz4NjsENClHRX3oBp1MSP0Dh UNIO+mUcoFcR3mN7e85s7bXPO Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org current_time is the last remaining caller of current_kernel_time64(), which is a wrapper around ktime_get_coarse_real_ts64(). This calls the latter directly for consistency with the rest of the kernel that is moving to the ktime_get_ family of time accessors, as now documented in Documentation/core-api/timekeeping.rst. An open questions is whether we may want to actually call the more accurate ktime_get_real_ts64() for file systems that save high-resolution timestamps in their on-disk format. This would add a small overhead to each update of the inode stamps but lead to inode timestamps to actually have a usable resolution better than one jiffy (1 to 10 milliseconds normally). Experiments on a variety of hardware platforms show a typical time of around 100 CPU cycles to read the cycle counter and calculate the accurate time from that. On old platforms without a cycle counter, this can be signiciantly higher, up to several microseconds to access a hardware clock, but those have become very rare by now. I traced the original addition of the current_kernel_time() call to set the nanosecond fields back to linux-2.5.48, where Andi Kleen added a patch with subject "nanosecond stat timefields". Andi explains that the motivation was to introduce as little overhead as possible back then. At this time, reading the clock hardware was also more expensive when most architectures did not have a cycle counter. One side effect of having more accurate inode timestamp would be having to write out the inode every time that mtime/ctime/atime get touched on most systems, whereas many file systems today only write it when the timestamps have changed, i.e. at most once per jiffy unless something else changes as well. That change would certainly be noticed in some workloads, which is enough reason to not do it without a good reason, regardless of the cost of reading the time. One thing we could still consider however would be to round the timestamps from current_time() to multiples of NSEC_PER_JIFFY, e.g. full milliseconds rather than having six or seven meaningless but confusing digits at the end of the timestamp. Signed-off-by: Arnd Bergmann -- changes in v2: * wait for Documentation to get merged first, as Dave Chinner requested * rewrite changelog based on discussion --- fs/inode.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) -- 2.18.0 diff --git a/fs/inode.c b/fs/inode.c index 462eb50b096f..c2dbab9a7cf5 100644 --- a/fs/inode.c +++ b/fs/inode.c @@ -2105,7 +2105,9 @@ EXPORT_SYMBOL(timespec64_trunc); */ struct timespec64 current_time(struct inode *inode) { - struct timespec64 now = current_kernel_time64(); + struct timespec64 now; + + ktime_get_coarse_real_ts64(&now); if (unlikely(!inode->i_sb)) { WARN(1, "current_time() called with uninitialized super_block in the inode");