[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] tools: delete gtraceview and gtracestat



On Fri, Sep 02, 2016 at 12:13:04PM +0100, George Dunlap wrote:
> On 02/09/16 12:07, Wei Liu wrote:
> > On Fri, Sep 02, 2016 at 12:05:49PM +0100, George Dunlap wrote:
> >> On 30/08/16 13:50, Ian Jackson wrote:
> >>> Wei Liu writes ("[PATCH] tools: delete gtraceview and gtracestat"):
> >>>> There has not been any substantial update to them since 2011. My quick
> >>>> check shows that they don't work.
> >>>>
> >>>> Just delete them. It would be easy to resurrect them from git log should
> >>>> people still need them.
> >>>
> >>> I'm not sure what these are.  git log is not particularly
> >>> illuminating.  gtraceview.c and some of the commit messages talk about
> >>> "Cx events" or "x86 Cx" and there is an Intel copyright notice, but
> >>> not Intel email addresses.
> >>>
> >>> There is also some discussion of xentrace in the source code.
> >>>
> >>> Are these the only in-tool consumer of some kind of hypervisor
> >>> -generated or -mediated data ?  If so it should be retained IMO, or
> >>> the corresponding hypervisor code removed too.
> >>>
> >>> I have added George to the CC in the hope that he may know more...
> >>
> >> Well I'd never looked at it before, but it does indeed seem to be
> >> something about skimming through xentrace records.
> >>
> >> The help for both functions says to run "xentrace -e 0x80f000", which
> >> will capture all events of type TRC_HW, which includes TRC_PM.  The code
> >> (again for both) then seems to parse events of type TRC_PM_IDLE_ENTRY,
> >> TRC_PM_IDLE_EXIT, and TRC_PM_FREQ_CHANGE.
> >>
> >> gtraceview seems to be an ncurses-based browser; gtracestat seems to be
> >> a xenalyze-style statistical analysis thing.
> >>
> >> So it would seem to be the case that they consume hypervisor-generated
> >> data, but they are not the *only* consumers of that data
> >> (xentrace_format and xenalyze being the other ones).
> >>
> >> When you say they "don't work", what do you mean?
> >>
> > 
> > Tried to run it. It failed to produce anything useful. It is bit-rotten.
> 
> You took a trace and passed the resulting binary to it then?

Yes.

> 
> If so, it's probably just the case that the trace record format has
> changed somewhat and these weren't updated.  It would probably be fairly
> straightforward to fix; but if nobody's using it, I'd just as soon
> delete it.  The "gtracestat" functionality would probably better be
> added to xenalyze in any case.
> 

Yes. I agree.

Wei.

>  -George
> 

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.