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

[Jimi Xenidis <jimix@xxxxxxxxxxxxxx>]

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.
(http://ltt.polymtl.ca/svn/ltt/branches/poly/doc/developer/xen-port.txt)

-JX

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!
>
> Cheers,
> Mark
>
> 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
> > Xen-devel@xxxxxxxxxxxxxxxxxxx
> > http://lists.xensource.com/xen-devel
> --
> 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@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel