Re: [RT] read_tsc: ACK! TSC went backward! Unsynced TSCs?

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

 



[email protected] writes:

> On Mon, Nov 28, 2005 at 12:39:28PM -0500, Lee Revell wrote:
> > On Mon, 2005-11-28 at 09:30 -0800, [email protected] 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 [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