Messages in this thread | | | Subject | Re: Dual core Athlons and unsynced TSCs | From | Steven Rostedt <> | Date | Fri, 13 Jan 2006 15:58:08 -0500 |
| |
On Fri, 2006-01-13 at 11:32 -0800, thockin@hockin.org wrote: > On Fri, Jan 13, 2006 at 10:56:13AM -0800, Sven-Thorsten Dietrich wrote: > > On Fri, 2006-01-13 at 10:55 -0800, thockin@hockin.org wrote: > > > 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... > > There's some chatter here about a solution involving a lazy sync of TSCs > to the HPET (or other) whenever an app calls rdtsc after a potentially > unsyncing event. > > For example, 'hlt' will initiate C1 which may cause clock ramping (and TSC > skew). We can trap rdtsc after a hlt and re-sync the TSCs to some truly > monotonic source, like HPET. > > I don't have all the details, some problems remain, and the work is not > quite done yet, but it looks promising. > > Even if we eventually get synced TSCs, it's too little too late. > basically, anything in-kernel that uses rdtsc is bound to break, and any > app that uses rdtsc had better be using CPU affinity.
I know this might be somewhat of an overhead, but what about resyncing on wakeup of the idle function? Isn't that where they fall apart?
-- Steve
- 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/
| |