>From: Dan Magenheimer
>Sent: 2008年7月2日 5:43
>
>Hi Andy --
>
>Thanks for the reply.
>
>No, I don't think the TSC offset capabilities in VT are sufficient.
>If you are migrating from a TSC-synchronized SMP system and TSC
>was selected as the clocksource by the guest at boot *because* TSC
>is always synchronized, and then you migrate to a system where TSC
>is not synchronized, Xen can synchronize it once at migrate time
>but then the TSC's on the target system will immediately start to
If dest and src boxes are with same bits, saying same tsc freq, then
the divergence is a fixed value and TSC offset adjustment is sufficient.
Or else TSC offset can't help.
>diverge. So TSC might be a reasonable clocksource on the first
>system but not on the target system. One could of course use
>CPUID to disallow a TSC-unsynchronized host as a suitable target
>for a TSC-synchronized-assumed guest, but that seems overly
>restrictive,
>especially if TSC wasn't selected as the clocksource for the guest
>and/or the guest (and its apps) isn't particularly time-sensitive.
So if it's an option instead of a 'NEVER' clause, I agree as:
a) user may mark TSC unstable to migrate among boxes with
mismatching TSC bits (bus crystal, cpu freq impact, etc.)
b) user may always use TSC as clocksource and then trap RDTSC
when migrating to a box with mismatching TSC bits
c) user may always use TSC as clocksource when migrating to a
box with same TSC bits, by adjusting TSC offset
d) migration may be prevented since no reliable methods to ensure
a)'s effect. Such prevention then falls into generic CPUID comparison
involved in migration
>
>> I don't know why you want to single out TSC here.
>
>I'm singleing it out because it is a per-cpu clock rather
>than a platform timer... a platform timer can be (and indeed
>is) offset'ed on migration and that is sufficient if it is
>selected as the clocksource.
The problem is not per-cpu vs platform, IMO. Instead, it's the
problem that currently guest TSC is conveyed by host TSC plus
an offset approach, without read trap. If you also virtualize a
platform clocksource by a real one, like dedicating a HPET ch,
same concern also raises.
>
>> That is what Linux is testing for anyways. If it decides it is
>> ok it is fine.
>
>Not sure... if Linux thinks it is running on a uniprocessor,
>but Xen reschedules this uniprocessor Linux guest on a different
>processor on the same physical SMP system, does Xen adjust the
>potential TSC difference? I could be wrong, but I think not.
Xen can do and should be, since SMP system is driven by same
crystal and thus host TSC is synced. But I guess by far Xen hasn't
do it, since the TSC drift (dozen of cycles) is smaller than the overhead
to migrate a vcpu. Thus guest won't observe a backward value in
theory.
>
>> The reason why it is an advantage to try to make TSC btw
>> is that it is *much* faster than any other timer and there
>> are definitely workloads that are very timer intensive.
Curiously, how much downgrade using a platform clock source may be,
for a time-intensive workload?
>
>Yes, understood, but if a timer-intensive application makes
>the assumption that TSC is synchronized and thus will never
>go backwards, but TSC is not synchronized and it DOES (apparently)
>go backwards due to Xen scheduler or migration, a slower timer
>might have been preferred.
Shouldn't this be a software bug instead?
Thanks,
Kevin
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home