From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH 1/2] trace: Add simple tracing support Date: Fri, 21 May 2010 15:22:26 +0200 Message-ID: <4BF68912.5030005@siemens.com> References: <1274434947-2863-1-git-send-email-stefanha@linux.vnet.ibm.com> <1274434947-2863-2-git-send-email-stefanha@linux.vnet.ibm.com> <4BF66AED.5080201@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Stefan Hajnoczi , "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" , Prerna Saxena , Anthony Liguori To: Stefan Hajnoczi Return-path: Received: from goliath.siemens.de ([192.35.17.28]:22986 "EHLO goliath.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753774Ab0EUNWm (ORCPT ); Fri, 21 May 2010 09:22:42 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: Stefan Hajnoczi wrote: > On Fri, May 21, 2010 at 12:13 PM, Jan Kiszka wrote: >> Stefan Hajnoczi wrote: >>> Trace events should be defined in trace.h. Events are written to >>> /tmp/trace.log and can be formatted using trace.py. Remember to add >>> events to trace.py for pretty-printing. >> When already writing to a file, why not reusing QEMU's logging >> infrastructure ("log " / "-d foo")? Shouldn't make a huge >> performance difference if the data is saved in clear-text. > >> Also, having support for ftrace's user space markers would be a very >> nice option (only an option as it's Linux-specific), see >> http://lwn.net/Articles/366796. > > Thanks for the links. > > I think using the platform's tracing facility has many advantages. > The main one being that we can focus on QEMU/KVM development rather > than re-implementing tracing infrastructure :). Indeed. :) > > It may be possible to have SystemTap, DTrace, or nop static trace > event code. A platform with no tracing support can only use the nop > backend, which results in a build without static trace events. > Platforms with tracing support can build with the appropriate backend > or nop. The backend tracing facility is abstracted and most of QEMU > doesn't need to know which one is being used. That would be ideal. > > I hadn't seen trace markers. However, I suspect they aren't ideal for > static trace events because logging an event requires a write system > call. They look useful for annotating kernel tracing information, but > less for high frequency/low overhead userspace tracing. You never know for sure until you tried :). There are surely lots of scenarios where this overhead does not matter. Moreover, I'm sure that something of LTTng's high-frequency/low-overhead tracing capabilities will make it (in whatever form) into mainline sooner or later. So we need that smart infrastructure to make use of it once it's available (actually, LTTng is already available, just still requires "some" kernel patching). Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=43985 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OFSCg-0007wt-7G for qemu-devel@nongnu.org; Fri, 21 May 2010 09:23:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OFSBT-0003Tt-Km for qemu-devel@nongnu.org; Fri, 21 May 2010 09:22:43 -0400 Received: from goliath.siemens.de ([192.35.17.28]:22966) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OFSBT-0003Sy-BH for qemu-devel@nongnu.org; Fri, 21 May 2010 09:22:39 -0400 Message-ID: <4BF68912.5030005@siemens.com> Date: Fri, 21 May 2010 15:22:26 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1274434947-2863-1-git-send-email-stefanha@linux.vnet.ibm.com> <1274434947-2863-2-git-send-email-stefanha@linux.vnet.ibm.com> <4BF66AED.5080201@siemens.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 1/2] trace: Add simple tracing support List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Anthony Liguori , Prerna Saxena , Stefan Hajnoczi , "kvm@vger.kernel.org" , "qemu-devel@nongnu.org" Stefan Hajnoczi wrote: > On Fri, May 21, 2010 at 12:13 PM, Jan Kiszka wrote: >> Stefan Hajnoczi wrote: >>> Trace events should be defined in trace.h. Events are written to >>> /tmp/trace.log and can be formatted using trace.py. Remember to add >>> events to trace.py for pretty-printing. >> When already writing to a file, why not reusing QEMU's logging >> infrastructure ("log " / "-d foo")? Shouldn't make a huge >> performance difference if the data is saved in clear-text. > >> Also, having support for ftrace's user space markers would be a very >> nice option (only an option as it's Linux-specific), see >> http://lwn.net/Articles/366796. > > Thanks for the links. > > I think using the platform's tracing facility has many advantages. > The main one being that we can focus on QEMU/KVM development rather > than re-implementing tracing infrastructure :). Indeed. :) > > It may be possible to have SystemTap, DTrace, or nop static trace > event code. A platform with no tracing support can only use the nop > backend, which results in a build without static trace events. > Platforms with tracing support can build with the appropriate backend > or nop. The backend tracing facility is abstracted and most of QEMU > doesn't need to know which one is being used. That would be ideal. > > I hadn't seen trace markers. However, I suspect they aren't ideal for > static trace events because logging an event requires a write system > call. They look useful for annotating kernel tracing information, but > less for high frequency/low overhead userspace tracing. You never know for sure until you tried :). There are surely lots of scenarios where this overhead does not matter. Moreover, I'm sure that something of LTTng's high-frequency/low-overhead tracing capabilities will make it (in whatever form) into mainline sooner or later. So we need that smart infrastructure to make use of it once it's available (actually, LTTng is already available, just still requires "some" kernel patching). Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux