>From: Dan Magenheimer
>Sent: 2008年7月2日 1:33
>
>Various versions of Linux under various circumstances select
>TSC as the primary clocksource for the kernel. This is
>especially true for uniprocessor kernels, but also in some
>cases for multiprocessor kernels. In most cases, this
>is because a processor bit (tsc_invariant? constant_tsc?)
>is passed through directly from the hardware via Xen and
>tested by the hvm guest and the result implies that the
>TSC is "stable".
constant_tsc is one of the factors affecting tsc stability, and
the keypoint is that one internal variable 'tsc_unstable' is
initialized to zero. That means, kernel considers TSC as
stable by default, and you need trigger some factors upon
which guest kernel'd like to mark tsc as unstable when
checking them. However by far none of those factors seem
appliable to all circumstances.
For example, even by hidding constant_tsc bit from cpuid,
UP guest will still consider tsc as stable, and so does 32bit
SMP guest running on Intel processors.
There's one proposal in KVM side, by exposing a faked C2
states into guest. ACPI processor idle path will mark TSC
as unstable when trying to enter C2. However that requires
guest to enable ACPI processor support, and need some
tricky logic to further mark C2 invalid to avoid performance
influence after purpose is achieved...
When saying this, I'm not opposing your proposal since it
does be a light option for some type of guests. My point is
just that no reliabe option to mark tsc as unstable, and
whether we have done all what can be done in Xen side
to tackle this issue... Sorry that I didn't follow up your
long discussion in this area before and thus may lose some
context.
>
>I'd like to propose that, for a Xen hvm guest, TSC should
>NEVER be considered stable. For at least these reasons:
>
>1) Often this test is done once at guest boot; if the guest
> migrates to another machine without the bit set, time
> will be erratic.
Since it's 'if', we should treat it as an option, instead of 'NEVER',
right? User may not have migration requirement in some cases,
and or the migratable backups are with same bits exactly... :-)
>2) I *think* that in some cases even within the same system,
> TSC values will skew somewhat. Since a uniprocessor guest
> will often be rescheduled to a different pcpu by Xen,
> the underlying tsc may appear erratic.
Can't be the tsc kept monotonic to guest, with some tweak on
tsc offset? Also Xen is always trying to sync tsc among cores.
As long as you don't run on a box with multiple bus crystals,
or a box without constant tsc upon freq change, the tsc drift
among cores should be negligible considering the overhead of
migration. Then for cases out of 'as long as', we should mark
TSC as unstable, still as an option.
>
>Comments (especially from Intel and AMD)?
>
>If agreed, could Intel and AMD provide patches so that hvm
>reads of the bits return "false"? Or will this cause other
>problems?
I vaguely recalled some posts about CPUID virtualization
framework. There's no need to a seperate category, and it
looks like this option can be aligned with that part?
Thanks,
Kevin
>
>Another alternative would be to trap all rdtsc's and emulate
>them but this probably will not be easy and may have
>significant performance implications. But perhaps it should
>be an option?
>
Agree.
Thanks,
Kevin
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home