Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 16 Apr 2013 17:25:02 -0700
From:      Jim Harris <jim.harris@gmail.com>
To:        Alexander Motin <mav@freebsd.org>
Cc:        "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>
Subject:   Re: Synchronizing TSC
Message-ID:  <CAJP=Hc8fzwZBCp-9K8dHP1HrMh7r62FHm%2BSKWooBf_yUGS6mFQ@mail.gmail.com>
In-Reply-To: <516DCAF7.20400@FreeBSD.org>
References:  <516DCAF7.20400@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Apr 16, 2013 at 3:04 PM, Alexander Motin <mav@freebsd.org> wrote:

> Hi.
>
> Recently I've got 6-core/12-thread system on Sandy Bridge-E Core i7-3930K
> CPU and was unpleasantly surprised to see that TSCs are not synchronized
> there. While all 11 APs were synchronized, BSP was far behind them. Since
> it is single-socket system, I don't know any good reason for such behavior
> except some BIOS bug. But I've recalled that somewhere was some discussions
> about possible TSC synchronization. I've implemented patch below that
> allows to adjust TSC values of BSPs to AP's one on boot using CPU MSRs,
> hoping that they should not diverge after that:
> http://people.freebsd.org/~**mav/tsc_adj2.patch<http://people.freebsd.org/~mav/tsc_adj2.patch>;
>
> I don't know very much about all different TSC hardware to predict when it
> is safe to enable the functionality, but at least on my system being
> enabled via loader tunable it seems working well.
>
> Comments?
>
>
You may be remembering this thread on r238755 last year:

http://lists.freebsd.org/pipermail/svn-src-head/2012-July/038992.html

This was a bug fix in the TSC synchronization test code though, not
anything for trying to adjust out-of-sync TSCs.

The Intel SDM (volume 3, section 17.13 of March 2013 revision) says earlier
models can only write to lower 32 bits of IA32_TIME_STAMP_COUNTER, but
these models also should not have invariant TSC so they would never even
get to your new routine.  So your patch seems OK for Intel CPUs, at least
as a tunable that is disabled by default.

My only concern would be why TSC on the BSP started out-of-sync on your
system.  Theoretically, BIOS could adjust TSCs in SMM to try to hide SMI
code execution from the OS, which could then make them out-of-sync again.
Not sure if that's what's happening here, but might be worth a test putting
the TSC test code on a periodic timer to see if they ever get out of sync
again.

-Jim



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJP=Hc8fzwZBCp-9K8dHP1HrMh7r62FHm%2BSKWooBf_yUGS6mFQ>