Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755750AbYAJVgp (ORCPT ); Thu, 10 Jan 2008 16:36:45 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752511AbYAJVgi (ORCPT ); Thu, 10 Jan 2008 16:36:38 -0500 Received: from mga11.intel.com ([192.55.52.93]:62630 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751421AbYAJVgh convert rfc822-to-8bit (ORCPT ); Thu, 10 Jan 2008 16:36:37 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.24,268,1196668800"; d="scan'208";a="283538780" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Subject: RE: [RFC PATCH 13/22 -v2] handle accurate time keeping over longdelays Date: Thu, 10 Jan 2008 13:33:09 -0800 Message-ID: <1FE6DD409037234FAB833C420AA843EC48842F@orsmsx424.amr.corp.intel.com> In-Reply-To: <1199996959.6108.18.camel@localhost.localdomain> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RFC PATCH 13/22 -v2] handle accurate time keeping over longdelays Thread-Index: AchTx499B/YJDmGUTsq8vtqFAfqDGwAB+3Rg References: <20080109232914.676624725@goodmis.org> <20080109233044.288563621@goodmis.org> <1199923219.6350.16.camel@localhost.localdomain> <12c511ca0801101154q224c7a43sa016190cf209d304@mail.gmail.com> <1199996959.6108.18.camel@localhost.localdomain> From: "Luck, Tony" To: "john stultz" , Cc: "Steven Rostedt" , "LKML" , "Ingo Molnar" , "Linus Torvalds" , "Andrew Morton" , "Peter Zijlstra" , "Christoph Hellwig" , "Mathieu Desnoyers" , "Gregory Haskins" , "Arnaldo Carvalho de Melo" , "Thomas Gleixner" , "Tim Bird" , "Sam Ravnborg" , "Frank Ch. Eigler" , "Steven Rostedt" X-OriginalArrivalTime: 10 Jan 2008 21:33:10.0239 (UTC) FILETIME=[659166F0:01C853D0] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 794 Lines: 19 > If you noticed in my email, the fix for ppc was a bit easier, as it has > only a 64bit counter that is quite unlikely to wrap twice between calls > to update_wall_time(). "quite unlikely" ... Hmmm just how fast are you driving the clocks on your ppc? Even at 100GHz It is almost SIX YEARS between wrap-arounds of a 64-bit counter. Perhaps you could just have a cron job that forces a call to update_wall_time() every January 1st, rather than add extra code overhead to a hot path :-) ? But I agree that narrower counters are a problem. -Tony -- 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/