Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934672AbdC3TwZ (ORCPT ); Thu, 30 Mar 2017 15:52:25 -0400 Received: from mail-it0-f44.google.com ([209.85.214.44]:35585 "EHLO mail-it0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934152AbdC3TwY (ORCPT ); Thu, 30 Mar 2017 15:52:24 -0400 MIME-Version: 1.0 In-Reply-To: <23410.1490902528@warthog.procyon.org.uk> References: <22214.1490895007@warthog.procyon.org.uk> <23410.1490902528@warthog.procyon.org.uk> From: Linus Torvalds Date: Thu, 30 Mar 2017 12:52:22 -0700 X-Google-Sender-Auth: e_mnEXvcDz_W7yz9wOyRCCoGyPM Message-ID: Subject: Re: Apparent backward time travel in timestamps on file creation To: David Howells Cc: Thomas Gleixner , John Stultz , Linux Kernel Mailing List , linux-fsdevel Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1430 Lines: 34 On Thu, Mar 30, 2017 at 12:35 PM, David Howells wrote: > Linus Torvalds wrote: > >> The difference can be quite noticeable - basically the >> "gettimeofday()" time will interpolate within timer ticks, while >> "xtime" is just the truncated "time at timer tick" value _without_ the >> correction. > > Is there any way to determine the error bar, do you know? Or do I just make > up a fudge factor? Hmm. The traditional error bar is just HZ. Which depends on architecture, but I don't think we've ever had anything below 100 on x86 (on other architectures it's been lower, like 24Hz on MIPS). I guess you could have missed timer ticks that makes it worse - we do have code to try to handle things like that. But in general, I think you should be able to more or less rely on that 100Hz error bar. I don't think tickless really changes that, because even the full tickless keeps ticks going on _some_ CPU to make xtime work. John should know the details better. Do we ever slow down from that? > Obviously the filesystem truncation would need to be taken into account (and > this can be different for different timestamps within the same filesystem). Yeah, for some filesystems the truncation issue is going to be the bigger one (eg truncate to one second or something). But likely those are not the ones you'd care to necessarily test. FAT? Linus