mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Paul Rolland" <rol@witbe.net>
To: Michael Tokarev <mjt@tls.msk.ru>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	rol@witbe.net
Subject: Re: constant_tsc and TSC unstable
Date: Fri, 30 Nov 2007 07:59:32 +0100	[thread overview]
Message-ID: <20071130075932.7f1f0974@tux.DEF.witbe.net> (raw)
In-Reply-To: <474F2E97.5080802@msgid.tls.msk.ru>

Hello,

On Fri, 30 Nov 2007 00:26:47 +0300
Michael Tokarev <mjt@tls.msk.ru> wrote:

> H. Peter Anvin wrote:
> > Paul Rolland (ポール・ロラン) wrote:
> []
> >> Measured 3978592228 cycles TSC warp between CPUs, turning off TSC clock.
> >> Marking TSC unstable due to: check_tsc_sync_source failed.
> []
> >> but I was wondering if this is a bug or a feature ;)
> 
> > The problem you're having is that the TSCs of your two cores are
> > completely different, over a second apart.  This is a bug, unrelated to
> > constant_tsc.
> 
> A bug in where - in the CPU or in kernel?
Good question !
 
> The thing is that all our dual-core machines shows something like
> that.
> 
> (not that huge difference as Paul reported, but still "unstable".
> The same happens with 2.6.23)
I've been checking my logs, and the difference is quite constant and
huge :
[root@tux log]# grep 'cycles TSC warp' messages*
messages:Nov 26 08:27:56 tux kernel: Measured 4078687691 cycles TSC warp between C
PUs, turning off TSC clock.
messages:Nov 26 17:21:21 tux kernel: Measured 3978592228 cycles TSC warp between C
PUs, turning off TSC clock.
messages.1:Nov 18 22:52:23 tux kernel: Measured 4063102940 cycles TSC warp between
 CPUs, turning off TSC clock.
messages.1:Nov 19 07:19:02 tux kernel: Measured 4057192061 cycles TSC warp between
 CPUs, turning off TSC clock.
messages.1:Nov 23 20:50:12 tux kernel: Measured 4064589321 cycles TSC warp between
 CPUs, turning off TSC clock.
messages.2:Nov 12 08:06:44 tux kernel: Measured 4072130361 cycles TSC warp between
 CPUs, turning off TSC clock.
messages.2:Nov 13 19:42:47 tux kernel: Measured 4049899451 cycles TSC warp between
 CPUs, turning off TSC clock.
messages.2:Nov 17 09:27:22 tux kernel: Measured 4066629060 cycles TSC warp between
 CPUs, turning off TSC clock.
messages.3:Nov  5 08:25:08 tux kernel: Measured 4086386109 cycles TSC warp between
 CPUs, turning off TSC clock.
messages.3:Nov  8 13:07:08 tux kernel: Measured 4041945934 cycles TSC warp between
 CPUs, turning off TSC clock.
messages.3:Nov  9 23:31:24 tux kernel: Measured 4092303059 cycles TSC warp between
 CPUs, turning off TSC clock.
messages.4:Oct 29 07:28:23 tux kernel: Measured 4096946373 cycles TSC warp between
 CPUs, turning off TSC clock.
messages.4:Oct 31 17:07:21 tux kernel: Measured 4046765372 cycles TSC warp between
 CPUs, turning off TSC clock.
messages.4:Oct 31 17:15:09 tux kernel: Measured 4039328228 cycles TSC warp between
 CPUs, turning off TSC clock.
messages.4:Oct 31 23:19:00 tux kernel: Measured 4069714246 cycles TSC warp between
 CPUs, turning off TSC clock.
messages.4:Nov  1 20:33:02 tux kernel: Measured 4088199726 cycles TSC warp between
 CPUs, turning off TSC clock.
messages.4:Nov  2 11:53:17 tux kernel: Measured 4079927527 cycles TSC warp between
 CPUs, turning off TSC clock.
messages.4:Nov  3 09:37:16 tux kernel: Measured 4071112656 cycles TSC warp between
 CPUs, turning off TSC clock.
messages.4:Nov  3 10:51:29 tux kernel: Measured 3986266219 cycles TSC warp between
 CPUs, turning off TSC clock.
messages.4:Nov  4 18:14:56 tux kernel: Measured 4074214144 cycles TSC warp between
 CPUs, turning off TSC clock.

> Note that once TSC is disabled (it's using "jiffies" as far
> as I can see), ntpd constantly speeds up and slows down the
> clock, it jumps +/- 0.5sec every several minutes or hours -
> I guess that's when ntpd process gets moved from one core
> to another for whatever reason.  And an interesting thing
> is that with 64bits kernel this TSC problem does not occur
> on this very machine.
Hmmmm.... That could make it a problem related to kernel rather than CPU.
 
> Something similar is reported on AMD X2 64 machines as well --
> can't check right now.
If I recall correctly, issues with AMD X2 where related to TSC being
independant for each core and not constant (speed depending of C state).
But the reason I raise the issue is that the Core2 reports constant TSC,
so there is (IMHO) no reason for that.

Paul


  reply	other threads:[~2007-11-30  6:59 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-29 16:11 Paul Rolland
2007-11-29 19:04 ` H. Peter Anvin
2007-11-29 21:26   ` Michael Tokarev
2007-11-30  6:59     ` Paul Rolland [this message]
2007-11-30  7:04       ` H. Peter Anvin
2007-11-29 21:36   ` Patrick McHardy
2007-11-29 23:29 ` Pallipadi, Venkatesh
2007-11-30  6:52   ` Paul Rolland (ポール・ロラン)
2007-12-06  0:35     ` Pallipadi, Venkatesh
2007-11-30  0:30 ` Frans Pop

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071130075932.7f1f0974@tux.DEF.witbe.net \
    --to=rol@witbe.net \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mjt@tls.msk.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome