From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Magenheimer Subject: RE: TSC virtualization across different host frequency platform migration Date: Wed, 22 Apr 2009 08:47:26 -0700 (PDT) Message-ID: References: <9832F13BD22FB94A829F798DA4A8280501A7D29D36@pdsmsx503.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <9832F13BD22FB94A829F798DA4A8280501A7D29D36@pdsmsx503.ccr.corp.intel.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Dong, Eddie" , xen-devel@lists.xensource.com Cc: "Tian, Kevin" , dan.magenheimer@oracle.com, Keir Fraser , "Zhang, Xiantao" List-Id: xen-devel@lists.xenproject.org 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@intel.com] > Sent: Tuesday, April 21, 2009 7:33 PM > To: xen-devel@lists.xensource.com > Cc: Tian, Kevin; Dong, Eddie; Keir Fraser; Zhang, Xiantao > Subject: [Xen-devel] TSC virtualization across different host=20 > frequency > platform migration >=20 >=20 > Keir and all: > =09Recently we are considering the potential issue of TSC=20 > virtualization across different frequency platform migration.=20 > Current approach will lead to synchronization issue between=20 > guest TSC and wall clock. Software trap and emulate can solve=20 > the problem with the payment of performance overhead which is=20 > not optimal. We want to propose smart scaling algorithm which=20 > can continuously use HW TSC_OFFSET and maintain long time=20 > synchronization of guest TSC. The details are in attached=20 > document. Can you have a look and provide comments? > =09Thanks. BTW of course PV time is another solution which=20 > is not covered in this proposal. >=20 > Eddie