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/
Home Products Support Community News


Re: [Xen-devel] Re: [PATCH 3/5] x86/pvclock: add vsyscall implementatio

To: Avi Kivity <avi@xxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH 3/5] x86/pvclock: add vsyscall implementation
From: john stultz <johnstul@xxxxxxxxxx>
Date: Wed, 4 Nov 2009 13:19:39 -0800
Cc: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, Jeremy Fitzhardinge <jeremy.fitzhardinge@xxxxxxxxxx>, kurt.hackel@xxxxxxxxxx, Glauber Costa <glommer@xxxxxxxxxx>, the arch/x86 maintainers <x86@xxxxxxxxxx>, Jeremy Fitzhardinge <jeremy@xxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, zach.brown@xxxxxxxxxx, Glauber de Oliveira Costa <gcosta@xxxxxxxxxx>, Ingo Molnar <mingo@xxxxxxxxxx>, chris.mason@xxxxxxxxxx
Delivery-date: Wed, 04 Nov 2009 13:21:09 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=Fwo6THYc42sXkFx9Yd5qDFOLcrANTLEu/DFwhDdMRqs=; b=e+W3L8u933hJ+jN7dAar+unqbQaUQE/JBh8Hy8Iil4jIQD/woG0J1HFBZf4PCjhpg4 6q1/36EiLH9vxMa2WI0cTqprAmHLIH0PWYWfU2V8Bjd4jhjLADsriAyoBnuNyO8cvjgZ PrB197ZTUwYFriLnn/catdjVkkOM6l/Yab0zo=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=eKSqYkrHH6H7Bk5xtkhjFdR4+WqGYGb3Vu2MhnOSoogZefwwMCQETtKX+JtC7DY+lF zPTFU9JL2dHfOJsl1OIOvBsG19OscrvnaK5Qbl4g++h/obO1shIbvKGbccL3gCSXSGAY OMZmKi2EbW9JhDFS6d5L9QKsd7nELtI155KSw=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4AE9AFAE.5020306@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>
References: <6137c066-3dfd-49dd-bbf2-7718f8542958@default> <4AE9AFAE.5020306@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Thu, Oct 29, 2009 at 7:07 AM, Avi Kivity <avi@xxxxxxxxxx> wrote:
> On 10/29/2009 04:46 PM, Dan Magenheimer wrote:
>> 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.
> Out of interest, do you know (and can you relate) why those apps need
> 100k/sec monotonically increasing timestamps?

This is sort of tangential, but depending on the need, this might be
of interest:  Recently I've added a new clock_id,
return a HZ granular timestamp (same granularity as filesystem
timestamps). Its very fast to access, since there's no hardware to
touch, and is accessible via vsyscall.

The idea being, if your hitting clock_gettime 100k/sec but you really
don't have the need for nsec granular timestamps, it might provide a
really nice performance boost.

Here's the commit:


Xen-devel mailing list

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