[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1FE6DD409037234FAB833C420AA843EC48842F@orsmsx424.amr.corp.intel.com>
Date: Thu, 10 Jan 2008 13:33:09 -0800
From: "Luck, Tony" <tony.luck@...el.com>
To: "john stultz" <johnstul@...ibm.com>, <bob.picco@...com>
Cc: "Steven Rostedt" <rostedt@...dmis.org>,
"LKML" <linux-kernel@...r.kernel.org>,
"Ingo Molnar" <mingo@...e.hu>,
"Linus Torvalds" <torvalds@...ux-foundation.org>,
"Andrew Morton" <akpm@...ux-foundation.org>,
"Peter Zijlstra" <a.p.zijlstra@...llo.nl>,
"Christoph Hellwig" <hch@...radead.org>,
"Mathieu Desnoyers" <mathieu.desnoyers@...ymtl.ca>,
"Gregory Haskins" <ghaskins@...ell.com>,
"Arnaldo Carvalho de Melo" <acme@...stprotocols.net>,
"Thomas Gleixner" <tglx@...utronix.de>,
"Tim Bird" <tim.bird@...sony.com>,
"Sam Ravnborg" <sam@...nborg.org>,
"Frank Ch. Eigler" <fche@...hat.com>,
"Steven Rostedt" <srostedt@...hat.com>
Subject: RE: [RFC PATCH 13/22 -v2] handle accurate time keeping over longdelays
> 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@...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