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: [PATCH 3/5] x86/pvclock: add vsyscall implementation

To: Avi Kivity <avi@xxxxxxxxxx>, Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: RE: [Xen-devel] Re: [PATCH 3/5] x86/pvclock: add vsyscall implementation
From: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Date: Thu, 29 Oct 2009 07:46:05 -0700 (PDT)
Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@xxxxxxxxxx>, kurt.hackel@xxxxxxxxxx, Glauber Costa <glommer@xxxxxxxxxx>, maintainers <x86@xxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Glauber de Oliveira Costa <gcosta@xxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, the, Ingo Molnar <mingo@xxxxxxxxxx>, zach.brown@xxxxxxxxxx, chris.mason@xxxxxxxxxx
Delivery-date: Thu, 29 Oct 2009 07:47:29 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4AE986FE.3040104@xxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> From: Avi Kivity [mailto:avi@xxxxxxxxxx]
> 
> On 10/28/2009 07:47 PM, Jeremy Fitzhardinge wrote:
> >> Much better to have an API for this.  Life is hacky enough already.
> >>      
> > My point is that if an app cares about property X then it 
> should just
> > measure property X.  The fact that gettimeofday is a 
> vsyscall is just an
> > implementation detail that apps don't really care about.  
> What they care
> > about is whether gettimeofday is fast or not.
> >    
> 
> But we can not make a reliable measurement.
> 
> > If the environment has such unstable timing that the effect can't be
> > measured, then it is moot whether its a vsyscall or not (but in that
> > case its almost certainly better to use the standard API rather than
> > trying to roll your own timesource with rdtsc).
> >    
> 
> If you're interested in gettimeofday() for a global monotonic counter 
> you can fall back to atomic_fetch_and_add() which will be 
> faster than a 
> syscall even on large systems.  Maybe we should provide a 
> vsyscall for 
> global monotonic counters and implement it using a atomics or tsc 
> instead of these hacks (I'm assuming here that the 
> gettimeofday() calls 
> are used to implement an atomic counter - are they?)

No, the apps I'm familiar with (a DB and a JVM) need a timestamp
not a monotonic counter.  The timestamps must be relatively
accurate (e.g. we've been talking about gettimeofday generically,
but these apps would use clock_gettime for nsec resolution),
monotonically increasing, and work properly across a VM
migration.  The timestamps are taken up to a 100K/sec or
more so the apps need to ensure they are using the fastest
mechanism available that meets those requirements.


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

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