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