> 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.
Yep, this is really something we should look about improving now.
> 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?
It's just there because it was simpler to implement. I'm confident that we
can come up with a more flexible format that won't have a detrimental effect
on performance / stability.
> 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).
Two record sizes might be an interesting compromise, but I suggest we go the
whole hog and spec a design for fully variable data lengths with a fixed
length header.
Cheers,
Mark
> -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!
--
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