[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |