From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jeremy Fitzhardinge <jeremy@goop.org>
Subject: Re: pvclock implementation in pv_ops kernel: why not
	__native_read_tsc()?
Date: Fri, 30 Oct 2009 18:17:48 -0700
Message-ID: <4AEB903C.5000704@goop.org>
References: <e7adfdc0-37e4-461d-bc07-fd71b86415a5@default>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xensource.com>
In-Reply-To: <e7adfdc0-37e4-461d-bc07-fd71b86415a5@default>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Cc: "Xen-Devel (E-mail)" <xen-devel@lists.xensource.com>
List-Id: xen-devel@lists.xenproject.org

On 10/30/09 16:30, Dan Magenheimer wrote:
> 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.
>   

I already changed it to __native_read_tsc() in xen.git, mostly because
the vsyscall code can't call kernel functions.  But I'm not sure what
the distinction is supposed to be.

> Any reason for this?  It seems an unnecessary extra
> function call for a routine that is used thousands
> of times every second.
>   

I suppose, but the function call is trivial compared to the cost of the
rdtsc itself, or even the lfence barriers surrounding it.

    J