Variable-length trace buffers would certainly be nice. Right now, for
some records, I'm squeezing bits into things, and just *one* more byte
would be great... but for other records, I'm storing 4 words of 0, and
there just doesn't seem to be any other useful information to add.
Keir, is the simpler, "one trace size fits all" method just because it
was easier to implement originally, or is the simplicity expected to
greatly reduce overhead and/or bugginess? If the former, then there
seems enough interest in making the tracing more flexible to be worth
changing; if the latter, then we should probably chose something and
live with it, or perhaps a compromise (i.e., two record sizes).
-George
On 11/30/06, Mark Williamson <mark.williamson@xxxxxxxxxxxx> 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
|
Home