From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hollis Blanchard Subject: Re: [PATCH 0 of 6] PowerPC KVM patches for 2.6.29 Date: Wed, 03 Dec 2008 13:31:17 -0600 Message-ID: <1228332677.10084.44.camel@localhost.localdomain> References: <49366E68.4080904@redhat.com> <1228320269.10084.7.camel@localhost.localdomain> <4936BC90.9060401@redhat.com> <1228332133.10084.42.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, kvm-ppc@vger.kernel.org, Christian Ehrhardt To: Avi Kivity Return-path: Received: from e31.co.us.ibm.com ([32.97.110.149]:56041 "EHLO e31.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751188AbYLCTbm (ORCPT ); Wed, 3 Dec 2008 14:31:42 -0500 In-Reply-To: <1228332133.10084.42.camel@localhost.localdomain> Sender: kvm-owner@vger.kernel.org List-ID: On Wed, 2008-12-03 at 13:22 -0600, Hollis Blanchard wrote: > On Wed, 2008-12-03 at 19:06 +0200, Avi Kivity wrote: > > Hollis Blanchard wrote: > > > > > >> I'm not thrilled about the private exit timing statistics gathering, > > >> hopefully it can be morphed into the more general framework. > > >> > > > > > > Is there anything in particular you have in mind? I think it could be > > > generally useful, but since x86 has hardware support for performance > > > monitoring, oprofile will already give you more accurate information. Of > > > course, I don't think you could extract standard deviation from an > > > oprofile report, and that has been very useful for us because it can > > > tell us e.g. 99% of instruction emulation is handled in the minimum > > > amount of time, but 1% takes hundreds of ms. > > > > > > > kvmtrace is basically a bunch of trace_marker()s sprinkled around the > > code. the marker infrastructure allow you to attach a callback to the > > markers, where you can do the accounting. The nice thing it can be > > switched off at runtime, being replaced by a nop so > > compiled-in-but-disabled overhead is very low. > > However, we grab timestamps extremely early and late in the exit > handlers, in contexts from which it is not safe to call C code. This is > really important because we need to be able to measure the time spent in > the interrupt handler assembly. For x86 that may be confined to a simple > inline asm statement, but the code in > arch/powerpc/kvm/booke_interrupts.S is non-trivial and worth measuring. Well, I suppose we could save the timestamp to the vcpu, and call kvmtrace code later using that data. I'll stop now and let Christian comment when he's back. :) -- Hollis Blanchard IBM Linux Technology Center