lkml.org 
[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?
From
Date
thockin@hockin.org writes:

> On Mon, Nov 28, 2005 at 12:39:28PM -0500, Lee Revell wrote:
> > On Mon, 2005-11-28 at 09:30 -0800, thockin@hockin.org 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.

-Andi
-
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/

\
 
 \ /
  Last update: 2005-11-29 10:40    [from the cache]
©2003-2011 Jasper Spaans