All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <compudj@krystal.dyndns.org>
To: xen-devel@lists.xensource.com
Cc: Jimi Xenidis <jimix@watson.ibm.com>,
	Robert Wisniewski <bob@watson.ibm.com>,
	michel.dagenais@polymtl.ca
Subject: LTTng Xen port
Date: Tue, 12 Dec 2006 12:29:23 -0500	[thread overview]
Message-ID: <20061212172923.GA24883@Krystal> (raw)
In-Reply-To: <200612010229.50206.mark.williamson@cl.cam.ac.uk>

Hi,

My name is Mathieu Desnoyers, I am the current maintainer of the Linux Trace
Toolkit project, known as LTTng. This is a tracer for the 2.6 Linux kernels
oriented towards high performance and real-time applications.

I have read your tracing thread and I am surprised to see how much things
you would like in a tracer are already implemented and tested in LTTng. I am
currently porting my tracer to Xen, so I think it might be useful for you to
know what it provides. My goal is to do not duplicate the effort and save
everyone some time.

Here follows some key features of LTTng :

Architecture independant data types
Extensible event records
Self-describing traces
Variable size records
Fast (200 ns per event record)
Highly reentrant
Does not disable interrupts
Does not take lock on the critical path
Supports NMI tracing
Analysis/visualization tool (LTTV)

Looking at the integration of the existing LTTng implementation into Xen, I
came up with those two points for my Christmas whichlist :

Additionnal functionnalities that would be nice to have in Xen :

- RCU-style updates : would allow freeing the buffers without impact on tracing.
    * I guess I could currently use :
      for_each_domain( d )
        for_each_vcpu( d, v )
          vcpu_sleep_sync(v);
      I think it will have a huge impact on the system, but it would only be
      performed before trace buffers free.

- Polling for data in Xen from a dom0 process.
  Xentrace currently polls the hypervisor each 100ms to see if there is data
  that needs to be consumed. Instead of an active polling, it would be nice to
  use the dom0 OS capability to put a process to sleep while waiting for a
  resource. It would imply creating a module, loaded in dom0, that would wait
  for a specific virq coming from the Hypervisor to wake up such processes.
  We could think of exporting a complete poll() interface through sysfs or
  procfs that would be a directory filled with the resources exported from the
  Hypervisor to dom0 (which could include wait for resource freed, useful when
  shutting down a domU instead of busy looping). It would help dom0 to schedule
  other processes while a process is waiting for the Hypervisor.


You might also be interested in looking at :
- the website (http://ltt.polymtl.ca)
- LTTng Xen port design document (this one is different from the one posted by
  Jimi)
  (http://ltt.polymtl.ca/svn/ltt/branches/poly/doc/developer/lttng-xen.txt)
- OLS 2006 paper "The LTTng tracer : A Low Impact Performance and Behavior
  Monitor for GNU/Linux"
  (http://ltt.polymtl.ca/papers/desnoyers-ols2006.pdf)


Questions and constructive comments are welcome.

Mathieu


OpenPGP public key:              http://krystal.dyndns.org:8080/key/compudj.gpg
Key fingerprint:     8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68 

  parent reply	other threads:[~2006-12-12 17:29 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-30  5:59 [RFC][PATCH] 0/3] [V2] Update xentrace to be compatable with PPC Tony Breeds
2006-11-30  5:59 ` [RFC][PATCH] 2/3] [TOOLS][XENTRACE] Update tools to write data to disk in a known endian'ness Tony Breeds
2006-11-30 13:12   ` Mark Williamson
2006-12-01  5:23     ` Tony Breeds
2006-12-04 18:22       ` Mark Williamson
2006-11-30 16:27   ` George Dunlap 
2006-12-01  5:43     ` Tony Breeds
2006-11-30  5:59 ` [RFC][PATCH] 3/3] [TOOLS][XENTRACE] Various tidyups to xentrace tools Tony Breeds
2006-11-30 12:57   ` Mark Williamson
2006-12-01  5:39     ` Tony Breeds
2006-11-30  5:59 ` [RFC][PATCH] 1/3] [XEN] Use explicit bit sized fields for exported xentrace data Tony Breeds
2006-11-30 13:02   ` Mark Williamson
2006-11-30 16:58   ` George Dunlap 
2006-11-30 17:03     ` Keir Fraser
2006-12-01  2:29       ` Mark Williamson
2006-12-01 11:32         ` Jimi Xenidis
2006-12-01 17:54         ` George Dunlap 
2006-12-01 18:37           ` Keir Fraser
2006-12-05 16:54             ` Mark Williamson
2006-12-05 20:05               ` George Dunlap
2006-12-06 16:10                 ` [RFC][PATCH] 1/3] [XEN] Use explicit bit sized fieldsfor " Ian Pratt
2006-12-07  2:43                   ` Mark Williamson
2006-12-07  5:29                     ` Tony Breeds
2006-12-07 10:32                   ` Keir Fraser
2006-12-07 14:21                     ` Ian Pratt
2006-12-07 18:25                       ` George Dunlap
2006-12-08 10:52                         ` [RFC][PATCH] 1/3] [XEN] Use explicit bit sizedfieldsfor " Ian Pratt
2006-12-08 20:28                           ` George Dunlap 
2006-12-04 18:20           ` [RFC][PATCH] 1/3] [XEN] Use explicit bit sized fields for " Mark Williamson
2006-12-12 17:29         ` Mathieu Desnoyers [this message]
2006-12-12 21:20           ` LTTng Xen port Ian Pratt
2006-12-12 22:14             ` Mathieu Desnoyers
2006-12-13  2:25               ` Tony Breeds
2006-12-15  5:02                 ` Mark Williamson
2006-12-28  3:08           ` M.A. Williamson
2007-03-09  1:20           ` LTTng Xen port : finally in a repository near you Mathieu Desnoyers
2007-06-25  8:43             ` INAKOSHI Hiroya
2007-06-27  0:37               ` Mark Williamson
2007-06-27 16:22                 ` Mathieu Desnoyers
2007-06-27 16:25                   ` Keir Fraser
2007-06-27 16:14               ` Mathieu Desnoyers
2007-06-28  5:07                 ` INAKOSHI Hiroya
2007-06-28  6:58                   ` Mathieu Desnoyers
2007-06-28 12:32                     ` INAKOSHI Hiroya
2007-06-28 15:08                       ` Mathieu Desnoyers
2007-06-29  0:19                         ` INAKOSHI Hiroya

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20061212172923.GA24883@Krystal \
    --to=compudj@krystal.dyndns.org \
    --cc=bob@watson.ibm.com \
    --cc=jimix@watson.ibm.com \
    --cc=michel.dagenais@polymtl.ca \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.