From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 2/5] kvmtrace: make cycle calculation architecture aware Date: Thu, 10 Jul 2008 16:32:29 +0300 Message-ID: <48760F6D.5000709@qumranet.com> References: <1215439013-11480-1-git-send-email-ehrhardt@linux.vnet.ibm.com> <4874821F.4060509@linux.vnet.ibm.com> <1215615799.22935.1.camel@localhost.localdomain> <200807101822.16163.sheng.yang@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, Hollis Blanchard , Christian Ehrhardt , cotte@de.ibm.com, xiantao.zhang@intel.com, kvm-ppc@vger.kernel.org To: "Yang, Sheng" Return-path: Received: from il.qumranet.com ([212.179.150.194]:12904 "EHLO il.qumranet.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758200AbYGJNcb (ORCPT ); Thu, 10 Jul 2008 09:32:31 -0400 In-Reply-To: <200807101822.16163.sheng.yang@intel.com> Sender: kvm-owner@vger.kernel.org List-ID: Yang, Sheng wrote: > On Wednesday 09 July 2008 23:03:19 Hollis Blanchard wrote: > >> On Wed, 2008-07-09 at 11:17 +0200, Christian Ehrhardt wrote: >> >>> So the question that is left before changing that is, if the >>> original author had something special in mind chosing cycles >>> here. I added Eric on CC for that. >>> >>> I wait with my resubmission of the patch series until all >>> architectures agree *hope* on using getnstimeofday() - after an >>> ack from all sides I would revise my patch series and submit that >>> changes alltogether. >>> >> I got an email bounce from Eric the last time I tried to email him, >> so I'm not sure he's still with Intel. >> >> However, I don't think he had any special intention; I think he was >> just porting xentrace to KVM. >> > > Eric had completed his internship in Intel, so... > > I like the term "timestamp" too. I think he used "cycles" only because > there is a function called get_cycles(). > > But instead of getnstimeofday(), I suggest using ktime_get() here. > It's little more precise than getnstimeofday(), and ktime_t is more > easily to be handled. And I think the overhead it brought can be > ignored too. > What is the overhead of ktime_get()? -- error compiling committee.c: too many arguments to function