From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hollis Blanchard Date: Mon, 07 Jul 2008 16:37:40 +0000 Subject: Re: [PATCH 2/5] kvmtrace: make cycle calculation architecture aware Message-Id: <1215448660.11175.15.camel@localhost.localdomain> List-Id: References: <1215439013-11480-1-git-send-email-ehrhardt@linux.vnet.ibm.com> <1215439013-11480-3-git-send-email-ehrhardt@linux.vnet.ibm.com> In-Reply-To: <1215439013-11480-3-git-send-email-ehrhardt@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ehrhardt@linux.vnet.ibm.com Cc: kvm@vger.kernel.org, avi@qumranet.com, kvm-ppc@vger.kernel.org On Mon, 2008-07-07 at 15:56 +0200, ehrhardt@linux.vnet.ibm.com wrote: > From: Christian Ehrhardt > > The current implementation of kvmtrace uses always a 64 bit cycle variable, > but get_cycles() which is used to fill it is "unsigned long" which might be 32 > bit. > This reduces the accuracy e.g. on embedded powerpc since we would have a 64bit > value but get_cycle() only returns the low 32 bit. > To solve that this patch introduces kvm_arch_trace_cycles() which allows us > to make this calculation architecture aware. That way every architecture can > insert whatever fits best for their "kvmtrace cycle counter". > > Signed-off-by: Christian Ehrhardt "cycles" is a very poor name, because that's not really what we're talking about at all. (Also, that function name made me wonder what a "trace cycle" is. :) I would strongly prefer using "timestamp" instead. It would be nice if we could rename the data structure too, but I'd settle for only properly naming the new architecture function hook. In fact, if we want to be rigorous about it, it should really be something like "nanoseconds" instead, so that userspace wouldn't need to perform awkward conversions of "cycles" or "timebase ticks" to real time. It looks like getnstimeofday() would do the trick, and that way we wouldn't need an arch-specific hook at all. -- Hollis Blanchard IBM Linux Technology Center From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hollis Blanchard Subject: Re: [PATCH 2/5] kvmtrace: make cycle calculation architecture aware Date: Mon, 07 Jul 2008 11:37:40 -0500 Message-ID: <1215448660.11175.15.camel@localhost.localdomain> References: <1215439013-11480-1-git-send-email-ehrhardt@linux.vnet.ibm.com> <1215439013-11480-3-git-send-email-ehrhardt@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, avi@qumranet.com, kvm-ppc@vger.kernel.org To: ehrhardt@linux.vnet.ibm.com Return-path: Received: from e2.ny.us.ibm.com ([32.97.182.142]:45038 "EHLO e2.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750804AbYGGQhb (ORCPT ); Mon, 7 Jul 2008 12:37:31 -0400 In-Reply-To: <1215439013-11480-3-git-send-email-ehrhardt@linux.vnet.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: On Mon, 2008-07-07 at 15:56 +0200, ehrhardt@linux.vnet.ibm.com wrote: > From: Christian Ehrhardt > > The current implementation of kvmtrace uses always a 64 bit cycle variable, > but get_cycles() which is used to fill it is "unsigned long" which might be 32 > bit. > This reduces the accuracy e.g. on embedded powerpc since we would have a 64bit > value but get_cycle() only returns the low 32 bit. > To solve that this patch introduces kvm_arch_trace_cycles() which allows us > to make this calculation architecture aware. That way every architecture can > insert whatever fits best for their "kvmtrace cycle counter". > > Signed-off-by: Christian Ehrhardt "cycles" is a very poor name, because that's not really what we're talking about at all. (Also, that function name made me wonder what a "trace cycle" is. :) I would strongly prefer using "timestamp" instead. It would be nice if we could rename the data structure too, but I'd settle for only properly naming the new architecture function hook. In fact, if we want to be rigorous about it, it should really be something like "nanoseconds" instead, so that userspace wouldn't need to perform awkward conversions of "cycles" or "timebase ticks" to real time. It looks like getnstimeofday() would do the trick, and that way we wouldn't need an arch-specific hook at all. -- Hollis Blanchard IBM Linux Technology Center