Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754565AbbBTNcD (ORCPT ); Fri, 20 Feb 2015 08:32:03 -0500 Received: from mx6-phx2.redhat.com ([209.132.183.39]:47850 "EHLO mx6-phx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752566AbbBTNcA (ORCPT ); Fri, 20 Feb 2015 08:32:00 -0500 Date: Fri, 20 Feb 2015 08:31:45 -0500 (EST) From: Jan Stancek To: Nishanth Aravamudan , John Stultz Cc: Thomas Gleixner , lkml , Ingo Molnar Message-ID: <560044319.15784061.1424439105260.JavaMail.zimbra@redhat.com> In-Reply-To: <20150219192840.GA2872@linux.vnet.ibm.com> References: <20150219183531.GA13745@linux.vnet.ibm.com> <20150219192840.GA2872@linux.vnet.ibm.com> Subject: Re: time / gtod seconds value out of sync? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.6] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF31 (Linux)/8.0.6_GA_5922) Thread-Topic: time / gtod seconds value out of sync? Thread-Index: +UH3XnQDlXgVtvgw178wiOZ84imtXQ== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4616 Lines: 132 ----- Original Message ----- > From: "Nishanth Aravamudan" > To: "John Stultz" > Cc: "Thomas Gleixner" , "lkml" , jstancek@redhat.com, "Ingo Molnar" > > Sent: Thursday, 19 February, 2015 8:28:40 PM > Subject: Re: time / gtod seconds value out of sync? > > Hi John! > > On 19.02.2015 [11:03:26 -0800], John Stultz wrote: > > Hey Nish! Long time! > > yep :) > > > On Thu, Feb 19, 2015 at 10:35 AM, Nishanth Aravamudan > > wrote: > > > Hi John, > > > > > > We're seeing an interesting issue with the openposix testcase > > > difftime/1-1, which basically calls gtod/time, sleeps, calls time/gtod, > > > > I'm not familiar with the test... Do you have a link? > > Sorry about that: > > http://sourceforge.net/projects/posixtest/files/posixtest/posixtestsuite-1.5.2/posixtestsuite-1.5.2.tar.gz/download > > conformance/interfaces/difftime/1-1.c > > It takes quite a few iterations in a loop, but it eventually fails with > mainline on both x86-64 and ppc64le. > > > > then difftime and sees if they disagree. The issue occurs with either > > > vDSO implementations or direct syscalls. > > > > > > We are seeing failures on ppc64le and x86_64 (probably other places too, > > > just not tested yet), because (I'm pretty sure), the time() syscalls > > > granularity is not accounting for the nsecs value at all. Instead, it > > > just returns get_seconds(). > > > > > > Right, so there is always a problem mixing calls of different > > granularity (similar issues crop up with gettimeofday() and filesystem > > timestamps), so the basis of the test worries me a little bit from the > > description, but I'd have to look at it to really get a sense. > > Yep, that makes sense to me too -- the only concern I had was that the > point where time() is returning X seconds, a simultaneous (theoretical) > call to gtod() would return the correct X+1 seconds (presuming nsecs had > exceeded 1000000000). > > > > In one case, I see, in sys_time(): > > > > > > [ 313.001823] NACC: timekeeping_get_ns = 1000121642 > > > [ 314.001889] NACC: timekeeping_get_ns = 188401 > > > > > > gtod correctly accumulates those nsecs into the secs value: > > > > > > ts->tv_sec = tk->xtime_sec; > > > nsecs = timekeeping_get_ns(&tk->tkr); > > > ts->tv_nsec = 0; > > > timespec64_add_ns(ts, nsecs); > > > > > > but time() does: > > > > > > return tk->xtime_sec; > > > > > > It seems like overkill to do the full timekeeping_get_ns() in time(), > > > > Right, so looking into the git history, > > f20bf6125605acbbc7eb8c9420d7221c91aa83eb (time: introduce > > xtime_seconds) changed this specifically for performance reasons > > (cc'ed Ingo here, in case he remembers more context). > > Ah I see. I can see the performance impact of calling into gtod being > high. > > > The idea that time() would be ok as being HZ granular, and its been > > this way since 2.6.23. Thus you have a < HZ sized window where > > gettimeofday() will return the next second before time() gets updated > > by the tick. Thanks John for the explanation, this made it clear for me. I wonder if this wouldn't be helpful NOTE in time(2) man page. > > Right. > > > > but maybe it's also necessary to account for leap seconds? That is, we > > > need to ensure that accumulate_nsecs_to_secs() has been called before > > > return tk->xtime_sec? > > > > So leapseconds are also applied at tick time, so I don't think you'd > > see any different behavior with them. > > Yep, ok. > > > There was a thread on this quite awhile back and I if I recall I think > > the general consensus was to keep time() tick granular (so it aligns > > with filesystem timestamps) and gettimeofday() hardware granular. > > Though we also introduced the CLOCK_REALTIME_COARSE to match > > sub-second filesystem timestamps as well. > > > > So yea... I don't think we want to make a change here, but maybe I'm > > not understanding the underlying issue... so feel free to push back > > here. :) > > Oh that's fine. I mostly wanted the subsystem experts to chime in on if > the the testcase was valid, etc. > > Jan, do you have any other concerns? No, I don't. Regards, Jan > > Thanks, > Nish > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/