From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Yang, Sheng" Subject: Re: [PATCH 2/5] kvmtrace: make cycle calculation architecture aware Date: Thu, 10 Jul 2008 18:22:15 +0800 Message-ID: <200807101822.16163.sheng.yang@intel.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> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Cc: Hollis Blanchard , Christian Ehrhardt , cotte@de.ibm.com, xiantao.zhang@intel.com, avi@qumranet.com, kvm-ppc@vger.kernel.org, eric.e.liu@intel.com To: kvm@vger.kernel.org Return-path: Received: from mga03.intel.com ([143.182.124.21]:45941 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752580AbYGJKVA (ORCPT ); Thu, 10 Jul 2008 06:21:00 -0400 In-Reply-To: <1215615799.22935.1.camel@localhost.localdomain> Content-Disposition: inline Sender: kvm-owner@vger.kernel.org List-ID: 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. -- Thanks Yang, Sheng