Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932098AbVLFKuu (ORCPT ); Tue, 6 Dec 2005 05:50:50 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751585AbVLFKuu (ORCPT ); Tue, 6 Dec 2005 05:50:50 -0500 Received: from mx3.mail.elte.hu ([157.181.1.138]:52609 "EHLO mx3.mail.elte.hu") by vger.kernel.org with ESMTP id S1751485AbVLFKut (ORCPT ); Tue, 6 Dec 2005 05:50:49 -0500 Date: Tue, 6 Dec 2005 11:50:54 +0100 From: Ingo Molnar To: Roman Zippel Cc: Ulrich Windl , john stultz , lkml , Darren Hart , Nishanth Aravamudan , Frank Sorenson , Thomas Gleixner Subject: Re: [PATCH 2/13] Time: Reduced NTP Rework (part 2) Message-ID: <20051206105054.GA29002@elte.hu> References: <4390E48E.4020005@mvista.com> <4395475C.21877.29399CFE@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de> <20051206072708.GA25129@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-ELTE-SpamScore: 0.0 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=0.0 required=5.9 tests=AWL autolearn=no SpamAssassin version=3.0.3 0.0 AWL AWL: From: address is in the auto white-list X-ELTE-VirusStatus: clean Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1660 Lines: 40 * Roman Zippel wrote: > On Tue, 6 Dec 2005, Ingo Molnar wrote: > > > > > I'm thinking about moving the leap second handling to a timer, with the > > > > new timer system it would be easy to set a timer for e.g. 23:59.59 and > > > > then set the time. This way it would be gone from the common path and it > > > > wouldn't matter that much anymore whether it's used or not. > > > > > > Will the timer solution guarantee consistent and exact updates? > > > > it would still be dependent on system-load situations. > > Interrupt-load, actually. yeah. To a smaller degree it would be dependent on generic system-load too. E.g. if some code keeps interrupts disabled for too long. But the main delay potential is from other interrupts, or from having too many timers to process. > > It's an > > interesting idea to use a timer for that, but there is no strict > > synchronization between "get time of day" and "timer execution", so any > > timer-based leap-second handling would be fundamentally asynchronous. I > > dont think we want that, leap second handling should be a synchronous > > property of 'time'. > > I'm not really sure what you're talking about. [...] doh, it was too early in the morning. Of course xtime is driven by interrupts just as much, so time updates are already 'asynchronous' and subject to interrupt delays. So your idea is perfectly fine. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/