Re: [Xen-devel] no cycles for certain xentrace entries

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

The reason for the parameter is that cycles take up space, and are
often redundant information.  An HVM_IOPORT_READ, for example, will
always occur shortly after a VMEXIT and before a VMENTER, both of
which have cycles.  Adding the cycles parameter doubles the size of
that record.  When taking long traces, every little bit of space
saving helps.

Have you tried using xenalyze to analyze your trace?

http://xenbits.xensource.com/ext/xenalyze.hg

It does all the hard work of sorting by TSC value, including trying to
infer tsc drift.  It's designed to handle records that don't have a
tsc value in a reasonable way.

 -George

On Wed, Sep 29, 2010 at 9:09 AM, Olaf Hering <olaf@xxxxxxxxx> wrote:
> On Tue, Aug 31, Olaf Hering wrote:
>
>> what is the reason for the empty tsc for some xentracing calls, like
>> TRC_HVM_IOPORT_READ?
>> It makes sorting the resulting logfile by tsc value difficult because
>> the 0 entries end up at the beginning of the logfile.
>
> This change appears to work for me.
> So, what is the reason for the cycles parameter to trace_var()?
>
> --- xen-4.0.1-testing.orig/xen/common/trace.c
> +++ xen-4.0.1-testing/xen/common/trace.c
> @@ -631,6 +631,7 @@ void __trace_var(u32 event, bool_t cycle
>     if( !tb_init_done )
>         return;
>
> +    cycles = 1;
>     /* Convert byte count into word count, rounding up */
>     extra_word = (extra / sizeof(u32));
>     if ( (extra % sizeof(u32)) != 0 )
>
>
>
> _______________________________________________
> 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