From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932422AbbFEJKY (ORCPT ); Fri, 5 Jun 2015 05:10:24 -0400 Received: from bombadil.infradead.org ([198.137.202.9]:50571 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932222AbbFEJKU convert rfc822-to-8bit (ORCPT ); Fri, 5 Jun 2015 05:10:20 -0400 Message-ID: <1433495408.1495.8.camel@twins> Subject: Re: [RFC][PATCH 4/4] time: Do leapsecond adjustment in gettime fastpaths From: Peter Zijlstra To: Richard Cochran Cc: John Stultz , Ingo Molnar , lkml , Prarit Bhargava , Daniel Bristot de Oliveira , Jan Kara , Jiri Bohac , Thomas Gleixner , Ingo Molnar , Shuah Khan Date: Fri, 05 Jun 2015 11:10:08 +0200 In-Reply-To: <20150605090433.GC1528@localhost.localdomain> 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> Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.