From: Joerg Roedel <joro@8bytes.org>
To: Andi Kleen <andi@firstfloor.org>
Cc: Joerg Roedel <joerg.roedel@amd.com>,
tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com,
linux-kernel@vger.kernel.org, benjamin.serebrin@amd.com,
vojtech@suse.cz
Subject: Re: Whats the purpose of get_cycles_sync()
Date: Wed, 31 Oct 2007 11:18:48 +0100 [thread overview]
Message-ID: <20071031101848.GD29700@8bytes.org> (raw)
In-Reply-To: <p73sl3s2w29.fsf@bingen.suse.de>
Hi Andi,
On Tue, Oct 30, 2007 at 09:21:02PM +0100, Andi Kleen wrote:
> "Joerg Roedel" <joerg.roedel@amd.com> writes:
>
> > I would like to answer what the special purpose of the get_cycles_sync()
> > function is in the x86 architecture. In special I ask myself why
> > this function has to be *sync*?
>
> Vojtech had one test that tested time monotonicity over CPUs
> and it constantly failed until we added the CPUID on K8 C stepping.
> He can give details on the test.
Interesting, I wasn't aware of that.
> I suspect the reason was because the CPU reordered the RDTSCs so that
> a later RDTSC could return a value before an earlier one. This can
> happen because gettimeofday() is so fast that a tight loop calling it can
> fit more than one iteration into the CPU's reordering window.
Ok, that is the reason why the get_cycles_sync() function only exists on
x86_64 and not on i386, because on i386 gettimeofday() is a real
syscall?
> That is why newer kernels use RDTSCP if available which doesn't need
> to be intercepted and is synchronous. And since all AMD SVM systems
> have RDTSCP they are fine.
The problem with KVM here is that they wan't to migrate guests between
Intel and AMD boxes. So they don't export RDTSCP or FEATURE_SYNC_TSC to
the guests in the CPUID calls. A 64bit Linux guest will execute the
CPUID in that function.
Joerg
prev parent reply other threads:[~2007-10-31 10:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-30 17:44 Whats the purpose of get_cycles_sync() Joerg Roedel
2007-10-30 20:21 ` Andi Kleen
2007-10-30 22:02 ` Vojtech Pavlik
2007-10-30 22:42 ` Andi Kleen
2007-10-31 10:23 ` Joerg Roedel
2007-10-31 10:18 ` Joerg Roedel [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=20071031101848.GD29700@8bytes.org \
--to=joro@8bytes.org \
--cc=andi@firstfloor.org \
--cc=benjamin.serebrin@amd.com \
--cc=hpa@zytor.com \
--cc=joerg.roedel@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=vojtech@suse.cz \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.