[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTi=cx31Mgfe7FxJz6LUmTKFR4=9KEBgbFsNLjiSE@mail.gmail.com>
Date: Wed, 18 Aug 2010 18:41:02 -0700
From: john stultz <johnstul@...ibm.com>
To: "J. Bruce Fields" <bfields@...ldses.org>
Cc: "Patrick J. LoPresti" <lopresti@...il.com>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
Andi Kleen <andi@...stfloor.org>,
linux-fsdevel@...r.kernel.org, linux-nfs@...r.kernel.org,
linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Proposal: Use hi-res clock for file timestamps
On Wed, Aug 18, 2010 at 11:12 AM, J. Bruce Fields <bfields@...ldses.org> wrote:
> I'm completely ignorant about higher-resolution time sources. Any
> recommended reading? What resolution do they actually provide, what's
> the expense of reading them, how reliable are they, and how do the
> answers to those questions vary across different hardware and kernel
> versions? A quick look at drivers/clocksource/ doesn't suggest
> simple answers.
Yea, there aren't simple answers. Clocksource hardware varies
drastically in resolution and access time across systems and
architectures. Further, clocksources may change while the system is
up, so we don't really expose the hardware resolution.
On x86, access latency varies from ~50ns (TSC) to ~1.3us (ACPI PM).
(And that is ignoring the PIT, which can be 18us per call - luckily
almost no hardware uses that). The resolution similarly scales from
sub-ns (TSC @ > 1ghz cpus) to ~279ns (ACPI PM). Of course, across
architectures you will see even more variance.
thanks
-john
--
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