From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 0 of 6] PowerPC KVM patches for 2.6.29 Date: Wed, 03 Dec 2008 19:06:24 +0200 Message-ID: <4936BC90.9060401@redhat.com> References: <49366E68.4080904@redhat.com> <1228320269.10084.7.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, kvm-ppc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Christian Ehrhardt To: Hollis Blanchard Return-path: In-Reply-To: <1228320269.10084.7.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org> Sender: kvm-ppc-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: kvm.vger.kernel.org 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. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html