From: Andreas Herrmann <andreas.herrmann3@amd.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Valdis.Kletnieks@vt.edu, Thomas Gleixner <tglx@linutronix.de>,
linux-kernel@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH] x86: c1e_idle: don't mark TSC unstable if CPU has invariant TSC
Date: Tue, 23 Sep 2008 07:42:48 +0200 [thread overview]
Message-ID: <20080923054248.GB16896@alberich.amd.com> (raw)
In-Reply-To: <20080920061457.GE25713@elte.hu>
On Sat, Sep 20, 2008 at 08:14:57AM +0200, Ingo Molnar wrote:
>
> * Andreas Herrmann <andreas.herrmann3@amd.com> wrote:
>
> > Currently the kernel assumes TSC is stable and there are various
> > places where Linux might spot when TSC is unstable. c1e_idle is one
> > such place. But it's wrong to mark TSC unstable for all AMD CPUs in
> > this function as newer CPU families have TSC's that are P- and C-state
> > invariant.
>
> i agree with the purpose of the patch (as it flags the first really sane
> TSC implementation on x86!!!) - but it would be nice to indicate this in
> a different CPU feature bit other than X86_FEATURE_CONSTANT_TSC, to
> reduce confusion. Perhaps introduce a virtual CPU feature bit for that?
Yes, I thought about it as well, but at the moment I don't see a big
benefit. I guess you mean that with a new feature bit we could skip
all those additional checks for good TSCs if the bit is set or exit
mark_tsc_unstable() early?
But I've observed on one test machine with a dual-core CPU that TSC's
were P- and C-state invariant but they also had a constant difference
which was large enough to cause a
"Measured ... cycles TSC warp between CPUs, turning off TSC clock"
message. It was a family 0x11 CPU which has invariant TSCs and
for it the X86_FEATURE_CONSTANT_TSC bit is set. But obviously both
cores' TSCs were not correctly synced among themselves at start time.
Thus I think the current behaviour of the kernel to check for good TSC
in different places is the right thing to do because it is robust enough
to detect such unexpected behaviour.
Regards,
Andreas
prev parent reply other threads:[~2008-09-23 5:43 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-18 19:12 Andreas Herrmann
2008-09-18 19:35 ` Valdis.Kletnieks
2008-09-19 17:20 ` Andreas Herrmann
2008-09-19 18:21 ` Thomas Gleixner
2008-09-20 6:14 ` Ingo Molnar
2008-09-23 5:42 ` Andreas Herrmann [this message]
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=20080923054248.GB16896@alberich.amd.com \
--to=andreas.herrmann3@amd.com \
--cc=Valdis.Kletnieks@vt.edu \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
/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
all inboxes | Powered by JetHome®