Re: 2.6.14-rc4-rt7

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



George Anzinger wrote:
Ingo Molnar wrote:

* George Anzinger <[email protected]> wrote:


The TSC is such a fast and, usually, accurate answer, I think it deserves a little effort to save it. With your new clock code I think we could use per cpu TSC counters, read the full 64 bits and, in real corner cases, even per cpu conversion "constants" and solve this problem.



the problem is, this is the same issue as 'boot-time TSC syncing', but in disguise: to get any 'per CPU TSC offset' you need to do exactly the same type of careful all-CPUs-dance to ensure that the TSCs were sampled at around the same moment in time!

The box where i have these small TSC inconsistencies shows that it's the bootup synchronization of TSCs that failed to be 100% accurate. Even a 2 usecs error in synchronization can show up as a time-warp - regardless of whether we keep per-CPU TSC offsets or whether we clear these offsets back to 0. So it is not a solution to do another type of synchronization dance. The only solution is to fix the boot-time synchronization (where the hardware keeps TSCs synchronized all the time), or to switch TSCs off where this is not possible.

I was rather thinking of only comparing a cup's TSC with the SAME cup's TSC. We only use the TSC to bridge from the latest update of the the clock to now and when we update the clock we capture (i.e. update this cup's last TSC value) the TSC on that CPU. If we also capture the system time then we have a set of (last TSC, sys clock) for each CPU. If we further, keep 64-bits of TSC, we don't really require each cpu to update the clock very often, or, we could force such and update from time to time as needed. This would not require the TSC to be synced at all and even if they had different rates we could add that to the per cpu data and cover that too.

Well fooie!  Still have to get them all in sync.  So this does not solve the problem.

What this does require is that we do a really good job of figuring the TSC multiplier, something we don't do at all well today (rc5-rt5 on my box is fast by ~15 sec/ day). We might also want to verify that we are not letting monotonic time be other than monotonic :)

As you might suspect, I have some ideas about how to do a much better job of figuring out the TSC multiplier.

--
George Anzinger   [email protected]
HRT (High-res-timers):  http://sourceforge.net/projects/high-res-timers/
-
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]
  Powered by Linux