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

[Wei Liu]

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.

Signed-off-by: Wei Liu 
---
Cc: Ian Jackson 
---
 .gitignore  |2 -
 .hgignore   |2 -
 tools/misc/Makefile |8 -
 tools/misc/gtracestat.c | 1110 --
 tools/misc/gtraceview.c |  ---
 5 files changed, 2233 deletions(-)
 delete mode 100644 tools/misc/gtracestat.c
 delete mode 100644 tools/misc/gtraceview.c

diff --git a/.gitignore b/.gitignore
index d193820..065a8a9 100644
--- a/.gitignore
+++ b/.gitignore
@@ -192,8 +192,6 @@ tools/misc/xen-livepatch
 tools/misc/xenperf
 tools/misc/xenpm
 tools/misc/xen-hvmctx
-tools/misc/gtraceview
-tools/misc/gtracestat
 tools/misc/xenlockprof
 tools/misc/lowmemd
 tools/misc/xencov
diff --git a/.hgignore b/.hgignore
index 0bd29a1..8342f36 100644
--- a/.hgignore
+++ b/.hgignore
@@ -205,8 +205,6 @@
 ^tools/misc/xenpm$
 ^tools/misc/xen-hvmctx$
 ^tools/misc/xen-lowmemd$
-^tools/misc/gtraceview$
-^tools/misc/gtracestat$
 ^tools/misc/xenlockprof$
 ^tools/misc/xencov$
 ^tools/pygrub/build/.*$
diff --git a/tools/misc/Makefile b/tools/misc/Makefile
index cee2b99..8152f7b 100644
--- a/tools/misc/Makefile
+++ b/tools/misc/Makefile
@@ -17,8 +17,6 @@ INSTALL_BIN+= xencov_split
 INSTALL_BIN += $(INSTALL_BIN-y)
 
 # Everything to be installed in regular sbin/
-INSTALL_SBIN   += gtracestat
-INSTALL_SBIN   += gtraceview
 INSTALL_SBIN   += xen-bugtool
 INSTALL_SBIN-$(CONFIG_MIGRATE) += xen-hptool
 INSTALL_SBIN-$(CONFIG_X86) += xen-hvmcrash
@@ -85,9 +83,6 @@ xenperf: xenperf.o
 xenpm: xenpm.o
$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
 
-gtracestat: gtracestat.o
-   $(CC) $(LDFLAGS) -o $@ $< $(APPEND_LDFLAGS)
-
 xenlockprof: xenlockprof.o
$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
 
@@ -110,9 +105,6 @@ xen-livepatch: xen-livepatch.o
 xen-lowmemd: xen-lowmemd.o
$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenevtchn) $(LDLIBS_libxenctrl) 
$(LDLIBS_libxenstore) $(APPEND_LDFLAGS)
 
-gtraceview: gtraceview.o
-   $(CC) $(LDFLAGS) -o $@ $< $(CURSES_LIBS) $(TINFO_LIBS) $(APPEND_LDFLAGS)
-
 xencov: xencov.o
$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
 
diff --git a/tools/misc/gtracestat.c b/tools/misc/gtracestat.c
deleted file mode 100644
index 67cb003..000
--- a/tools/misc/gtracestat.c
+++ /dev/null
@@ -1,1110 +0,0 @@
-/*
- * gtracestat.c: list the statistics information for a dumped xentrace file.
- * Copyright (c) 2009, Intel Corporation.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms and conditions of the GNU General Public License,
- * version 2, as published by the Free Software Foundation.
- *
- * This program is distributed in the hope it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
- * more details.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program; If not, see .
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-#include 
-
-#define CHECK_DUP_CX 0
-
-/** MACROS **/
-#define MAX_CPU_NR  32
-#define MAX_CX_NR   8
-#define MAX_MODE_NR 16
-#define MAX_PX_NR  100
-
-/* simplified xentrace record */
-struct rec {
-uint64_t tsc;
-int cpu;
-unsigned char cx;
-unsigned char irqs[4];
-unsigned int predicted;
-unsigned int expected;
-int px;
-};
-
-/** FORWARD DECLARATION **/
-static void show_help(void);
-static void show_version(void);
-static int load_file(char *fname);
-static void do_digest(uint64_t start, uint64_t end, uint64_t scale);
-static void do_breakevents(void);
-static void do_count(void);
-static void do_px_count(void);
-static void do_maxmin(void);
-static void do_average(void);
-static void do_exp_ratio(void);
-static void do_exp_pred(void);
-
-/** GLOBAL VARIABLES **/
-/* store simplified xentrace data */
-static struct rec *data;
-static int64_t data_nr, data_cur;
-/* store max cx state number and cpu number */
-static int max_cx_num = -1, max_cpu_num = -1;
-static int px_freq_table[MAX_PX_NR];
-static int max_px_num = 0;
-
-static int is_menu_gov_enabled = 0;
-
-/* user specified translation unit */
-static uint64_t tsc2ms = 2793000UL;
-static uint64_t tsc2us = 2793UL;
-static uint64_t tsc2phase = 5580UL;
-
-/* each cpu column width */
-static int width = 0;
-
-/* digest mode variables */
-static struct rec *evt[MAX_CPU_NR];
-static int evt_len[MAX_CPU_NR];
-

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

[Ian Jackson]

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...

Thanks,
Ian.

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

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

[George Dunlap]

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?

 -George

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

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

[Wei Liu]

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.

Wei.

>  -George

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

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

[George Dunlap]

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?

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.

 -George


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

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

[Wei Liu]

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@lists.xen.org
https://lists.xen.org/xen-devel

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

[Ian Jackson]

Wei Liu writes ("Re: [PATCH] tools: delete gtraceview and gtracestat"):
> On Fri, Sep 02, 2016 at 12:13:04PM +0100, George Dunlap wrote:
> > 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.

OK, thanks for the discussion.  I'm sold.

Acked-by: Ian Jackson 

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

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

[Wei Liu]

On Fri, Sep 02, 2016 at 12:36:21PM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [PATCH] tools: delete gtraceview and gtracestat"):
> > On Fri, Sep 02, 2016 at 12:13:04PM +0100, George Dunlap wrote:
> > > 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.
> 
> OK, thanks for the discussion.  I'm sold.
> 
> Acked-by: Ian Jackson 

Pushed with your ack. Thanks.

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