From patchwork Fri Dec 7 13:48:23 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Arnd Bergmann X-Patchwork-Id: 10718157 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 55A201759 for ; Fri, 7 Dec 2018 13:49:52 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 464D12E5B4 for ; Fri, 7 Dec 2018 13:49:52 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 3A2FC2E7E5; Fri, 7 Dec 2018 13:49:52 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id D8A542E5E0 for ; Fri, 7 Dec 2018 13:49:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726095AbeLGNtp (ORCPT ); Fri, 7 Dec 2018 08:49:45 -0500 Received: from mout.kundenserver.de ([212.227.126.134]:46225 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726059AbeLGNt1 (ORCPT ); Fri, 7 Dec 2018 08:49:27 -0500 Received: from wuerfel.lan ([109.192.41.194]) by mrelayeu.kundenserver.de (mreue011 [212.227.15.129]) with ESMTPA (Nemesis) id 1MJmX3-1gkrXY12oj-00K5H1; Fri, 07 Dec 2018 14:49:01 +0100 From: Arnd Bergmann To: y2038@lists.linaro.org Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-sh@vger.kernel.org, Baolin Wang , Andrew Morton , John Stultz , Alexander Viro , Thomas Gleixner , Rich Felker , Yoshinori Sato , Arnd Bergmann Subject: [PATCH 7/8] vfs: replace current_kernel_time64 with ktime equivalent Date: Fri, 7 Dec 2018 14:48:23 +0100 Message-Id: <20181207134824.300024-8-arnd@arndb.de> X-Mailer: git-send-email 2.18.0 In-Reply-To: <20181207134824.300024-1-arnd@arndb.de> References: <20181207134824.300024-1-arnd@arndb.de> X-Provags-ID: V03:K1:/PWWtMTAj7kH3IX8FIHaCh0M4ZVgezPmBZs+fNsTAGU/xKCysp8 dL1kT65HFb01mnt9LbC25fw4I9taGCHDZ7iyww/h0B54yAz+S3XluCxtTq7JwLRpd3eP/Vk dLnCg79x8l7iPHfhhKj2XG91qvOvVX6MQ/Utqc/01ovw3KIOCZDZFDJCMqelq3kCPbHJSby UObdskdXz+J5ViYiPwYvA== X-UI-Out-Filterresults: notjunk:1;V03:K0:TN0H1/fwOtw=:By9RfTk590MZiC4vntyyQ5 fbOdGN36gwZf/zI0N7orC4+OfgmATkMGOmkFkS2OJLu7O5t7wFxEOYFlmxvffT+P6d9Y0oZNC NF+FfpOD9EsKrDfzRcasCYnHNWdt8dcOjGkNRfoNSuQVSpeAMaHpwPkY/RjMEFTu5PNzwRRgv ZoW1z+8yzUulzNHAn8jBNKY12QpJW/ezW2SrQujLhOdi6WpdCilcYRRFwJf+3wxoBHxcY7VrN dIu/bxnr2Mi+fPxTuIskLui2vx5kInvB7HOdRl2jvJiXKHtHrRUGnZmr9s1AJj4rJXzsya1FL jl3gX8KIBgd814Ioctnf9B954YWyNKFtVNoYdGGBQLAqJ2cjadjEeIbozCci/O8Fc9kzM+dxl Ec3BJq5dwFl8WfmxNuw2szW8x1/y4CQIYR2j0DPPdftEi9tEc8F5A9jaP13c9BFbqZX0nPO04 i2wLI0E9bLyeq3dg2s6+Aj3ocdxrcoovfe3rXmEo7GqYbhTxH1zQ1fVJZzq7IZW0M+MOsRU3N VYbSVh9jCX8OI5gOVOsQvCKSQ2FbZ+LtYSLM03oPtTub0PsGsAlAv6unS5WrvCOvAgr+PbfFe G4XN0tVvFhHtxSXmNPph+5fLUjAT6GMWp5y3mCZwHwVLZmiqTUbw+ftaGm1wlN722YtC/Nt7D VWjzjXIb5B0oWyhUvdIEwM2vfM6s57OxTjKjXKrPoZHz4fx6As958V2BHmggfrb90a97d7AyS SucssamhWShBmaN6UH++D5cPVBdLF3Wfe8cKtw== Sender: linux-sh-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-sh@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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. Link: http://lkml.kernel.org/r/20180726130820.4174359-1-arnd@arndb.de Signed-off-by: Arnd Bergmann --- fs/inode.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/fs/inode.c b/fs/inode.c index 9e198f00b64c..73432e64f874 100644 --- a/fs/inode.c +++ b/fs/inode.c @@ -2146,7 +2146,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");