From mboxrd@z Thu Jan 1 00:00:00 1970 From: Prerna Saxena Subject: Re: [Qemu-devel] [RFC 0/2] Tracing Date: Fri, 21 May 2010 16:57:37 +0530 Message-ID: <4BF66E29.5000101@linux.vnet.ibm.com> References: <1274434947-2863-1-git-send-email-stefanha@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org, Anthony Liguori To: Stefan Hajnoczi Return-path: Received: from e23smtp09.au.ibm.com ([202.81.31.142]:34562 "EHLO e23smtp09.au.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752896Ab0EUL1p (ORCPT ); Fri, 21 May 2010 07:27:45 -0400 Received: from d23relay04.au.ibm.com (d23relay04.au.ibm.com [202.81.31.246]) by e23smtp09.au.ibm.com (8.14.3/8.13.1) with ESMTP id o4LBRe4o014367 for ; Fri, 21 May 2010 21:27:40 +1000 Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96]) by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o4LBKURo1441986 for ; Fri, 21 May 2010 21:20:30 +1000 Received: from d23av01.au.ibm.com (loopback [127.0.0.1]) by d23av01.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o4LBRhCm013709 for ; Fri, 21 May 2010 21:27:43 +1000 In-Reply-To: <1274434947-2863-1-git-send-email-stefanha@linux.vnet.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: Hi Stefan, Nice to see the patchset. I am working on something similar, on the lines of static trace events for QEMU, that collect traces in a qemu-internal buffer. This would employ monitor commands to read traces, as well as enable/disable trace events at runtime. I plan to post a prototype early next week. On 05/21/2010 03:12 PM, Stefan Hajnoczi wrote: > Trace events in QEMU/KVM can be very useful for debugging and performance > analysis. I'd like to discuss tracing support and hope others have an interest > in this feature, too. > > Following this email are patches I am using to debug virtio-blk and storage. > The patches provide trivial tracing support, but they don't address the details > of real tracing tools: enabling/disabling events at runtime, no overhead for > disabled events, multithreading support, etc. > > It would be nice to have userland tracing facilities that work out-of-the-box > on production systems. Unfortunately, I'm not aware of any such facilities out > there right now on Linux. Perhaps SystemTap userspace tracing is the way to > go, has anyone tried it with KVM? > > For the medium term, without userspace tracing facilities in the OS we could > put something into QEMU to address the need for tracing. Here are my thoughts > on fleshing out the tracing patch I have posted: > > 1. Make it possible to enable/disable events at runtime. Users enable only the > events they are interested in and aren't flooded with trace data for all > other events. > Agree, my upcoming patchset should address this. > 2. Either make trace events cheap or build without trace events by default. > Disable by default still allows tracing to be used for development but > less for production. > I'm trying to do this too, though quite a lot remains to be improved in my current implementation :-) > 3. Allow events in any execution context (cpu, io, aio emulation threads). > Agree. > 4. Make it easy to add new events. Agree ! I'm trying to provide a unified macro interface like trace events which makes it easy enough to add new events. Regards, -- Prerna Saxena Linux Technology Centre, IBM Systems and Technology Lab, Bangalore, India