[lkml]   [2005]   [Nov]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RT] read_tsc: ACK! TSC went backward! Unsynced TSCs?
Date writes:

> On Mon, Nov 28, 2005 at 12:39:28PM -0500, Lee Revell wrote:
> > On Mon, 2005-11-28 at 09:30 -0800, wrote:
> > > The kernel's use of TSC is wholly incorrect. TSCs can ramp up and
> > > down and *do* vary between nodes as well as between cores within a
> > > node. You really can not compare TSCs between cpu cores at all, as is
> > > (and the kernel assumes 1 global TSC in at least a few places).
> >
> > That's one way to look at it; another is that the AMD dual cores have a
> > broken TSC implementation. The kernel's use of the TSC was never a
> > problem in the past...
> Sure. But the OS can be fixed, the chips can not. That said, I'd like to
> see a spec that says TSCs are a) synced, b) linear.

They have specs that say they're not. Intel has specs that say that they
are on newer systems, but at least one chipset breaks it.

Linear they are never because there are MSRs to change them.

But I'm surprised you're saying 2.6.11 broke. At least 2.6.11 64bit should
have always used HPET in this case. I only broke it around 2.6.13
where I added an overeager optimization for single socket DC on my side based
on a misunderstanding. Earlier and later kernels should have been ok.

32bit might have been different.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-11-29 10:40    [W:0.059 / U:0.092 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site