Re: [Xen-devel] [PATCH v2 0/2] xentrace: Add TRC_HVM_VCHIP (was xentrace: Add TRC_HW_VCHIP).

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

On 04/01/2014 04:18 PM, Don Slutz wrote:
> On 04/01/14 09:06, George Dunlap wrote:
> > On 03/28/2014 04:56 PM, Don Slutz wrote:
> > > Changes v1 to v2:
> > >    Tim Deegan:
> > >      Switch from TRC_HW_VCHIP to TRC_HVM_VCHIP.
> > >      Drop get_cycles()
> > >      Fix coding style issues.
> > >      Drop code that should not have been included.
> > >      Use names not numbers.
> > >
> > > Split in 2 patches for simpler review.
> > >
> > > Here is a subset of sample output:
> > Are you aware of xenalyze?  It's got a lot of advantages over
> > xentrace_format; the most basic of which is that it traces vcpus as
> > they run across pcpus.
> I have noticed that it exists.  Not sure it would help with the issue I
> was looking into.
>
> I have determined that I would see:
>
> CPU5  841028423232 (+    3900)  hpet create [ tn = 0, irq = 0, delta =
> 68718266336, period = 1000000 ]
>
> If I had been able to reproduce my issue.
Sure; but if you ever need to track a vcpu as it moves across pcpus, or 
see how the interaction of two vcpus cause an issue that you're seeing, 
xentrace_format isn't going to help you.
Additionally, with xenalyze it's a lot easier to add ad-hoc warnings or 
statistics gathering patches.
> Do I need to make a change there also?
If you want to use xenalyze to analyze your traces, it would probably 
make it a lot easier. :-)  (xenalyze will dump records it doesn't 
recognize in a sort of binary format, but that's probably not what you 
want.)
As it's out-of-tree, there's certainly no *requirement* for you to make 
a change there as a follow-up to this series.
 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel