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

[Xen-devel] pvclock implementation in pv_ops kernel: why not __native_re

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: [Xen-devel] pvclock implementation in pv_ops kernel: why not __native_read_tsc()?
From: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Date: Fri, 30 Oct 2009 16:30:39 -0700 (PDT)
Cc: "Xen-Devel \(E-mail\)" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 30 Oct 2009 16:32:17 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4AE883B9.4050409@xxxxxxxx>
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
Hi Jeremy --

I was looking at rdtsc usages in 2.6.31... you may
or may not be surprised to hear that there is exactly
one usage location, at least through boot and some
basic NFS copying: native_read_tsc().  Digging through
the pvclock code, I see that pvclock calls native_read_tsc()
rather than use the __native_read_tsc() inline function.
Any reason for this?  It seems an unnecessary extra
function call for a routine that is used thousands
of times every second.

Dan

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