[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALAqxLX8XV7Ay5gmsZVTYLwwPKr-FSKfCWYwJtNpNxruD1N5Ag@mail.gmail.com>
Date: Tue, 31 May 2016 16:11:02 -0700
From: John Stultz <john.stultz@...aro.org>
To: Thomas Graziadei <thomas.graziadei@...cronenergy.com>
Cc: lkml <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Tony Luck <tony.luck@...el.com>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>
Subject: Re: [PATCH] timekeeping: Fix 1ns/tick drift with GENERIC_TIME_VSYSCALL_OLD
On Tue, May 31, 2016 at 6:06 AM, Thomas Graziadei
<thomas.graziadei@...cronenergy.com> wrote:
> From: Thomas Graziadei <thomas.graziadei@...cronenergy.com>
>
> The user notices the problem in a raw and real time drift, calling
> clock_gettime with CLOCK_REALTIME / CLOCK_MONOTONIC_RAW on a system
> with no ntp correction taking place (no ntpd or ptp stuff running).
Hmm.. Curious. Was it actually drifting, or was it just
oscillating/ringing near the RAW clock's value?
> The problem is, that old_vsyscall_fixup adds an extra 1ns even though
> xtime_nsec is already held in full nsecs and the remainder in this
> case is 0. Do the rounding up buisness only if needed.
The patch looks ok. But I'm curious what architecture you were seeing
this on (ia64, powerpc?), as it would be much nicer to have those
architectures migrate off of the old low-res vsyscall calculation and
use the newer method with sub-ns precision, instead of trying to
further fix up the deprecated method.
I had submitted a patch to convert ia64 awhile back, but I don't
recall getting much feedback.
thanks
-john
Powered by blists - more mailing lists