lkml.org 
[lkml]   [2015]   [Feb]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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
    > <nacc@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



    \
     
     \ /
      Last update: 2015-02-19 20:41    [W:4.782 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site