[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150605072913.GD19282@twins.programming.kicks-ass.net>
Date: Fri, 5 Jun 2015 09:29:13 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: John Stultz <john.stultz@...aro.org>
Cc: Ingo Molnar <mingo@...nel.org>,
lkml <linux-kernel@...r.kernel.org>,
Prarit Bhargava <prarit@...hat.com>,
Daniel Bristot de Oliveira <bristot@...hat.com>,
Richard Cochran <richardcochran@...il.com>,
Jan Kara <jack@...e.cz>, Jiri Bohac <jbohac@...e.cz>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
Shuah Khan <shuahkh@....samsung.com>
Subject: Re: [RFC][PATCH 4/4] time: Do leapsecond adjustment in gettime
fastpaths
On Thu, Jun 04, 2015 at 05:08:11PM -0700, John Stultz wrote:
> I'm not sure how this follows. Leap smearing is a different behavior
> and I'd like to support it (as a separate clockid) as well, but adding
> that support doesn't change that the existing behavior applying the
> leapsecond to UTC/CLOCK_REALTIME via a timer results in behavior that
> isn't strictly correct.
So the big problem of course is that your patches do not handle the VDSO
time read, and that is the biggest source of userspace time.
So userspace will still see incorrect time, only in-kernel users (timers
being your prime example) get the leap second at the 'right' place.
Also note that your argument that timers will now get the correct time
is subject to the very same timer interrupt jitter as driving the leap
second stuff from an hrtimer itself -- they're all timers.
That leaves the question; for who is this exact second edge important?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists