The patch titled
Subject: vfs: replace current_kernel_time64 with ktime equivalent
has been added to the -mm tree. Its filename is
vfs-replace-current_kernel_time64-with-ktime-equivalent.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/vfs-replace-current_kernel_time64-with-ktime-equivalent.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/vfs-replace-current_kernel_time64-with-ktime-equivalent.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Arnd Bergmann <arnd@xxxxxxxx>
Subject: vfs: replace current_kernel_time64 with ktime equivalent
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@xxxxxxxx
Signed-off-by: Arnd Bergmann <arnd@xxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
fs/inode.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff -puN fs/inode.c~vfs-replace-current_kernel_time64-with-ktime-equivalent fs/inode.c
--- a/fs/inode.c~vfs-replace-current_kernel_time64-with-ktime-equivalent
+++ a/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");
_
Patches currently in -mm which might be from arnd@xxxxxxxx are
kasan-only-select-slub_debug-with-sysfs=y.patch
eventfs-include-linux-errnoh-in-header.patch
firewire-use-64-bit-time_t-based-interfaces.patch
ufs-use-ktime_get_real_seconds-for-sb-and-cg-timestamps.patch
ntfs-use-timespec64-directly-for-timestamp-conversion.patch
hpfs-extend-gmt_to_local-conversion-to-64-bit-times.patch
ocfs2-dlmglue-clean-up-timestamp-handling.patch
shmem-use-monotonic-time-for-i_generation.patch
mm-zsmalloc-make-several-functions-and-a-struct-static-fix.patch
procfs-uptime-use-ktime_get_boottime_ts64.patch
crash-print-timestamp-using-time64_t.patch
nilfs2-use-64-bit-superblock-timstamps.patch
reiserfs-use-monotonic-time-for-j_trans_start_time.patch
reiserfs-remove-obsolete-print_time-function.patch
reiserfs-change-j_timestamp-type-to-time64_t.patch
fat-propagate-64-bit-inode-timestamps.patch
adfs-use-timespec64-for-time-conversion.patch
sysvfs-use-ktime_get_real_seconds-for-superblock-stamp.patch
vmcore-hide-vmcoredd_mmap_dumps-for-nommu-builds.patch
treewide-convert-iso_8859-1-text-comments-to-utf-8.patch
s390-ebcdic-convert-comments-to-utf-8.patch
lib-fonts-convert-comments-to-utf-8.patch
vfs-replace-current_kernel_time64-with-ktime-equivalent.patch
--
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
