From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932079AbbFFJoI (ORCPT ); Sat, 6 Jun 2015 05:44:08 -0400 Received: from www.linutronix.de ([62.245.132.108]:37752 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751302AbbFFJoC (ORCPT ); Sat, 6 Jun 2015 05:44:02 -0400 Date: Sat, 6 Jun 2015 11:44:00 +0200 (CEST) From: Thomas Gleixner To: Peter Zijlstra cc: Richard Cochran , John Stultz , Ingo Molnar , lkml , Prarit Bhargava , Daniel Bristot de Oliveira , Jan Kara , Jiri Bohac , Ingo Molnar , Shuah Khan Subject: Re: [RFC][PATCH 4/4] time: Do leapsecond adjustment in gettime fastpaths In-Reply-To: <1433495408.1495.8.camel@twins> Message-ID: References: <1432931068-4980-1-git-send-email-john.stultz@linaro.org> <1432931068-4980-5-git-send-email-john.stultz@linaro.org> <20150602090154.GA2590@gmail.com> <20150603090452.GA9490@gmail.com> <20150604064809.GA14685@gmail.com> <20150605072913.GD19282@twins.programming.kicks-ass.net> <20150605090433.GC1528@localhost.localdomain> <1433495408.1495.8.camel@twins> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 5 Jun 2015, Peter Zijlstra wrote: > On Fri, 2015-06-05 at 11:04 +0200, Richard Cochran wrote: > > On Fri, Jun 05, 2015 at 09:29:13AM +0200, Peter Zijlstra wrote: > > > That leaves the question; for who is this exact second edge important? > > > > Distributed applications using the UTC time scale. > > > > Many control applications are done with a 1 millisecond period. > > Having the time wrong by a second for 10 or 100 loops is bad news. > > Firstly I would strongly suggest such applications not use UTC because > of this, I think TAI was invented for just this reason. > > Secondly, how would John's patches help with this? Usespace loops > reading time would be using the VDSO and would still not get the right > time, and timers would be subject to the same IRQ latency that a hrtimer > based leap second insert would, and would still very much not be in-sync > across the cluster. So the only thing which is fixed are in kernel users and therefor hrtimers. That means the whole leap mess added into the gettime fast path is just constant overhead for that corner case. We can be smarter than that and just block hrtimer delivery for clock realtime timers across the leap edge. There should be ways to do that non intrusive if we think hard enough about it. Thanks, tglx