[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] LTTng Xen port


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 )
      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
- OLS 2006 paper "The LTTng tracer : A Low Impact Performance and Behavior
  Monitor for GNU/Linux"

Questions and constructive comments are welcome.


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

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.