* John Stultz <john.stu...@linaro.org> wrote:
> > [ 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).
>
> 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.
Yes, and the scalability advantage is significant if you
have an app that calls time() often. Undoing that would
certainly make me sad.
Thanks,
Ingo
--
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/
