[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-ia64-devel] SMP guest and itc


  • To: <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Luck, Tony" <tony.luck@xxxxxxxxx>
  • Date: Tue, 14 Feb 2006 15:32:20 -0800
  • Delivery-date: Tue, 14 Feb 2006 23:44:20 +0000
  • List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
  • Thread-index: AcYxXMr4neN3EeYcTG2bQb5r7Qu9NQAYFR0Q
  • Thread-topic: [Xen-ia64-devel] SMP guest and itc

>Base on my understanding, the ITC drift between different processor
>after fixup done in Linux or Xen today is less than 100ns. So I think
>that is not a big issue as if we guarantee the guest doesn't  see
>backward time.

The context switch time of Xen or Linux doesn't matter.  The worst case
scenario that you need to cope with has no context switches.  Imagine
an application with two threads that are currently both running each
on their own cpu:

Thread #1                Thread #2
gettimeofday(&t1)
sync-primitive()         sync-primitive()
                         gettimeofday(&t2)


Where "sync-primitive()" is any of the many possible techniques
that user applications might use to handle synchronization between
user-mode threads.

In this case t2 must be greater than (or plausibly equal to) t1.

In response to another question in this thread: Yes, gettimeofday()
is a heavily used system call.  Some applications (e.g. databases)
like to timestamp a lot of things as they flow through the system.
I've been told around two gettimeofday() calls per SQL statement, with
usually a few SQL statements per transaction.

-Tony

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.