From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:39317) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R38VO-0000E4-IZ for qemu-devel@nongnu.org; Mon, 12 Sep 2011 11:33:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R38VN-0007JX-Ek for qemu-devel@nongnu.org; Mon, 12 Sep 2011 11:33:06 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48169) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R38VN-0007JQ-4h for qemu-devel@nongnu.org; Mon, 12 Sep 2011 11:33:05 -0400 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p8CFX3Gf021202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 12 Sep 2011 11:33:03 -0400 Message-ID: <4E6E262E.6060400@redhat.com> Date: Mon, 12 Sep 2011 11:33:02 -0400 From: William Cohen MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------080805080007000101020802" Subject: [Qemu-devel] Using the qemu tracepoints with SystemTap List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org, SystemTAP This is a multi-part message in MIME format. --------------080805080007000101020802 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi All, The RHEL-6 version of qemu-kvm makes the tracepoints available to SystemTap. I have been working on useful examples for the SystemTap tracepoints in qemu. There doesn't seem to be a great number of examples showing the utility of the tracepoints in diagnosing problems. However, I came across the following blog entry that had several examples: http://blog.vmsplice.net/2011/03/how-to-write-trace-analysis-scripts-for.html I reimplemented the VirtqueueRequestTracker example from the blog in SystemTap (the attached virtqueueleaks.stp). I can run it on RHEL-6's qemu-kvm-0.12.1.2-2.160.el6_1.8.x86_64 and get output like the following. It outputs the pid and the address of the elem that leaked when the script is stopped like the following: $ stap virtqueueleaks.stp ^C pid elem 19503 1c4af28 19503 1c56f88 19503 1c62fe8 19503 1c6f048 19503 1c7b0a8 19503 1c87108 19503 1c93168 ... I am not that familiar with the internals of qemu. The script seems to indicates qemu is leaking, but is that really the case? If there are resource leaks, what output would help debug those leaks? What enhancements can be done to this script to provide more useful information? Are there other examples of qemu probing people would like to see? -Will --------------080805080007000101020802 Content-Type: text/plain; name="virtqueueleaks.stp" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="virtqueueleaks.stp" # virtqueueleaks.stp # # virtqueueleaks.stp is based on the VirtqueueRequestTracker from: # http://blog.vmsplice.net/2011/03/how-to-write-trace-analysis-scripts-for.html global elems probe qemu.kvm.virtqueue_pop { elems[pid(),elem] = elem } probe qemu.kvm.virtqueue_fill { delete elems[pid(),elem] } probe end { printf("\n%8s %8s\n", "pid", "elem") foreach([p+, elem] in elems) { printf("%8d %8x\n", p, elem) } } --------------080805080007000101020802--