RE: [Xen-devel] TSC virtualization across different host frequency platform migration

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

Hi Eddie/Kevin --

I'm sorry to be dense, but I don't understand the
details of your solution.  I'm also not sure I
understand the problem you are trying to solve.
The problem description doesn't describe a problem,
just an event.

I'm guessing the problem is:  When a guest chooses
TSC as its primary clocksource AND a migration later
occurs to a host with a different TSC frequency
THEN wallclock time (e.g. the "date" command)
becomes incorrect.

I'm also guessing that you are NOT trying to solve
the problem:  An application that uses TSC
heavily to measure the passage of time AND
calibrates TSC on host A AND invisibly
migrates to host B with a different TSC
frequency THEN will NOT be able to accurately
measure the passage of time.  However, it will
continue to be monotonically increasing.

In other words, you are trying to solve the OS problem
but not the application problem.

Is this correct?  If so, then I think I understand
your proposal.

Also, I think it would be worthwhile to remeasure the
cost of trapping every TSC read, using current
processors and with some attempt in Xen to make
the emulation fast (returning Xen system time).
10% seems like a VERY large number, even if a database
is using TSC read to timestamp every transaction.

If software-emulated TSC read can be made fast enough,
then it solves both the OS and application problem.

Dan

> -----Original Message-----
> From: Dong, Eddie [mailto:eddie.dong@xxxxxxxxx]
> Sent: Tuesday, April 21, 2009 7:33 PM
> To: xen-devel@xxxxxxxxxxxxxxxxxxx
> Cc: Tian, Kevin; Dong, Eddie; Keir Fraser; Zhang, Xiantao
> Subject: [Xen-devel] TSC virtualization across different host 
> frequency
> platform migration
> 
> 
> Keir and all:
>       Recently we are considering the potential issue of TSC 
> virtualization across different frequency platform migration. 
> Current approach will lead to synchronization issue between 
> guest TSC and wall clock. Software trap and emulate can solve 
> the problem with the payment of performance overhead which is 
> not optimal. We want to propose smart scaling algorithm which 
> can continuously use HW TSC_OFFSET and maintain long time 
> synchronization of guest TSC.  The details are in attached 
> document. Can you have a look and provide comments?
>       Thanks. BTW of course PV time is another solution which 
> is not covered in this proposal.
> 
> Eddie

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel