On Fri, 13 Jan 2006, Lee Revell wrote:
On Fri, 2006-01-13 at 10:56 -0800, Sven-Thorsten Dietrich wrote:
On Fri, 2006-01-13 at 10:55 -0800, [email protected] wrote:
On Fri, Jan 13, 2006 at 01:09:51PM -0500, Lee Revell wrote:
Some apps/users need higher resolution and lower overhead that only rdtsc
can offer currently.
But obviously if the TSC gives wildly inaccurate results, it cannot be
used no matter how low the overhead.
unless we can re-sync the TSCs often enough that apps don't notice.
You'd have to quantify that somehow, in terms of the max drift rate
(ppm), and the max resolution available (< tsc frequency).
Either that, or track an offset, and use one TSC as truth, and update
the correction factor for the other TSCs as often as needed, maybe?
This is kind of analogous to the "drift" NTP calculates against a
free-running oscillator.
So you'd be pushing that functionality deeper into the OS-core.
Dave Mills had that "hardpps" stuff in there for a while, it might be a
starting point.
Just some thoughts for now...
It kind of makes you wonder what in the heck AMD were thinking, whether
they realized that this design decision would cause so many problems at
the OS level (it's broken at least Linux and Solaris). Maybe Windows
keeps time in a way that was unaffected by this?
Lee, the last time I saw this discussion I thought it was identified that
the multiple cores (or IIRC the multiple chips in a SMP motherboard) would
only get out of sync when power management calls were made (hlt or
switching the c-state). IIRC the workaround that was posted then was to
just disable these in the kernel build.
if this is the case then I could easily see the hardware engineers
thinking that if the software did a sleep thing then it was up to the
software to re-sync the TSC clocks when the wakeup takes place.
David Lang
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]