WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [RFC][PATCH] 1/3] [XEN] Use explicit bit sized fields fo

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] [RFC][PATCH] 1/3] [XEN] Use explicit bit sized fields for exported xentrace data.
From: Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Date: Fri, 1 Dec 2006 02:29:49 +0000
Cc: George Dunlap <dunlapg@xxxxxxxxx>, Keir Fraser <keir@xxxxxxxxxxxxx>, Tony Breeds <tony@xxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 30 Nov 2006 18:26:35 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C194BF5E.5504%keir@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C194BF5E.5504%keir@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.9.5
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

<Prev in Thread] Current Thread [Next in Thread>