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

Re: [Xen-devel] [RFC][PATCH] 1/3] [XEN] Use explicit bit sized fields for exported xentrace data.

I'll go one (huge) step further...
should we adopt LTTng? http://ltt.polymtl.ca/
The trace stanzas are well defined and comes with a bunch of visualization and analysis tools. I know a lot of people in at IBM have been using it for performance studies of various operating systems and I have been asked how Xen could support if for Xen but for domains as well.


On Nov 30, 2006, at 9:29 PM, Mark Williamson wrote:

I guess one possibility would be to continue using unsigned longs but store the machine word size and endianness in a header in the trace file. This
gets us platform independence.

This avoids adding extra overhead on the fast path, the extra processing can happen offline (and probably not at all in the common case that you're on the
same endianness / word size as the trace was collected on).

Another alternative would be to allow some combination of 32-bit or (fewer) 64-bit words in the record. This would let us keep the same record size, but
have a bit more flexibility.

Going the whole hog, we could even make the trace data opaque to trace.c -
have a char[] for the data, and deal with the semantics in terms
of "longs" "u64" etc in macros in the traced code, and in xentrace_format.

If we did this, the logical extension would be to have variable length trace records with a fixed-size header giving the full length. I think this would be a good direction to go in, and would ensure that we maximise use of the trace buffer space. It shouldn't be that hard to modify the system to do
this - most of the work may even be in making it nice to use!


On Thursday 30 November 2006 17:03, Keir Fraser wrote:
On 30/11/06 16:58, "George Dunlap" <dunlapg@xxxxxxxxx> wrote:
Hmm... this has the unfortunate side-effect of doubling the size of
the trace, and effectively halving the effectiveness of the trace
buffer in avoiding drops.  My moderate-length traces are already in
the gigabyte range, and I occasionally lose trace records even with a
buffer size of 256.  It would be really nice if we could avoid that.

I happen to be using the VMENTER/VMEXIT tracing, which could be
consolidated into one record if we went to a 64-bit trace. Is anyone
else doing high-bandwidth tracing that this would affect in a
significantly negative way?

As we move increasingly towards x86/64 this is an issue that will need to
be addressed even if we leave the tracing fields as longs.

 -- Keir

Xen-devel mailing list

Dave: Just a question. What use is a unicyle with no seat? And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

Xen-devel mailing list

Xen-devel mailing list



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