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 > <n...@linux.vnet.ibm.com> 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. 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? Thanks, Nish -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
