WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] RE: rdtsc: correctness vs performance on Xen (and KVM?)

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] RE: rdtsc: correctness vs performance on Xen (and KVM?)
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Wed, 02 Sep 2009 15:05:49 -0700
Cc: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, "Xen-Devel \(E-mail\)" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 02 Sep 2009 15:06:20 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C6C4A72F.13BDD%keir.fraser@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C6C4A72F.13BDD%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.1) Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Lightning/1.0pre Thunderbird/3.0b3
On 09/02/09 14:50, Keir Fraser wrote:
>> Yes.  Perhaps the very simplest way would be to make the kernel update
>> the pvclock version counter on context switch, the same way Xen does;
>> that would allow the usermode vsyscall code to use exactly the same
>> algorithm as the kernel code.  Would Xen cope with that?
>>     
> Yes, that's basically how I would envision it working. The main missing
> detail afaics is how to manage and access the required per-thread data.
>   

I was imagining:

   1. Add a hypercall to set the desired location of the clock
      correction info rather than putting it in the shared-info area
      (akin to vcpu placement).  KVM already has this; they write the
      address to a magic MSR.
   2. Pack all the clock structures into a single page, indexed by vcpu
      number
   3. Map that RO into userspace via fixmap, like the vsyscall page itself
   4. Use the lsl trick to get the current vcpu to index into the array,
      then compute a time value using tsc with corrections; iterate if
      version stamp changes under our feet.
   5. On context switch, the kernel would increment the version of the
      *old* vcpu clock structure, so that when the usermode code
      re-checks the version at the end of its time calculation, it can
      tell that it has a stale vcpu and it needs to iterate with a new
      vcpu+clock structure

    J

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

<Prev in Thread] Current Thread [Next in Thread>