On Sat, May 27, 2017 at 1:04 AM, Paul Mackerras <pau...@ozlabs.org> wrote: > This converts the powerpc VDSO time update function to use the new > interface introduced in commit 576094b7f0aa ("time: Introduce new > GENERIC_TIME_VSYSCALL", 2012-09-11). Where the old interface gave > us the time as of the last update in seconds and whole nanoseconds, > with the new interface we get the nanoseconds part effectively in > a binary fixed-point format with tk->tkr_mono.shift bits to the > right of the binary point. > > With the old interface, the fractional nanoseconds got truncated, > meaning that the value returned by the VDSO clock_gettime function > would have about 1ns of jitter in it compared to the value computed > by the generic timekeeping code in the kernel. > > The powerpc VDSO time functions (clock_gettime and gettimeofday) > already work in units of 2^-32 seconds, or 0.23283 ns, because that > makes it simple to split the result into seconds and fractional > seconds, and represent the fractional seconds in either microseconds > or nanoseconds. This is good enough accuracy for now, so this patch > avoids changing how the VDSO works or the interface in the VDSO data > page. > > This patch converts the powerpc update_vsyscall_old to be called > update_vsyscall and use the new interface. We convert the fractional > second to units of 2^-32 seconds without truncating to whole nanoseconds. > (There is still a conversion to whole nanoseconds for any legacy users > of the vdso_data/systemcfg stamp_xtime field.) > > In addition, this improves the accuracy of the computation of tb_to_xs > for those systems with high-frequency timebase clocks (>= 268.5 MHz) > by doing the right shift in two parts, one before the multiplication and > one after, rather than doing the right shift before the multiplication. > (We can't do all of the right shift after the multiplication unless we > use 128-bit arithmetic.) > > Signed-off-by: Paul Mackerras <pau...@ozlabs.org>
Apologies again for missing this earlier. So no objections from me. I can't say I really worked the whole thing out, but you're handling the xtime_nsec field properly and the rest looks reasonable and is well documented. So for what its worth: Acked-by: John Stultz <john.stu...@linaro.org> Thanks again for making this update! -john