Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1236373 > unrolled thread

[PATCHv2 00/45] perf stat: Add scripting support

Started byJiri Olsa <jolsa@kernel.org>
First post2015-09-30 16:20 +0200
Last post2015-09-30 23:40 +0200
Articles 4 on this page of 24 — 3 participants

Back to article view | Back to linux.kernel


Contents

  [PATCHv2 00/45] perf stat: Add scripting support Jiri Olsa <jolsa@kernel.org> - 2015-09-30 16:20 +0200
    [PATCH 44/45] perf script: Add python support for stat events Jiri Olsa <jolsa@kernel.org> - 2015-09-30 16:20 +0200
    [PATCH 40/45] perf script: Process stat config event Jiri Olsa <jolsa@kernel.org> - 2015-09-30 16:20 +0200
    [PATCH 05/45] perf tools: Add cpu_map event synthesize function Jiri Olsa <jolsa@kernel.org> - 2015-09-30 16:20 +0200
    [PATCH 29/45] perf tools: Add data arg to cpu_map__build_map callback Jiri Olsa <jolsa@kernel.org> - 2015-09-30 16:20 +0200
    [PATCH 34/45] perf stat report: Add support to initialize aggr_map from file Jiri Olsa <jolsa@kernel.org> - 2015-09-30 16:20 +0200
    [PATCH 30/45] perf stat report: Cache aggregated map entries in extra cpumap Jiri Olsa <jolsa@kernel.org> - 2015-09-30 16:20 +0200
    [PATCH 09/45] perf tools: Add stat config event read function Jiri Olsa <jolsa@kernel.org> - 2015-09-30 16:30 +0200
    [PATCH 18/45] perf stat: Add AGGR_UNSET mode Jiri Olsa <jolsa@kernel.org> - 2015-09-30 16:30 +0200
    [PATCH 11/45] perf tools: Add stat event synthesize function Jiri Olsa <jolsa@kernel.org> - 2015-09-30 16:30 +0200
    [PATCH 17/45] perf stat: Rename perf_stat struct into perf_stat_evsel Jiri Olsa <jolsa@kernel.org> - 2015-09-30 16:30 +0200
    [PATCH 23/45] perf stat record: Add pipe support for record command Jiri Olsa <jolsa@kernel.org> - 2015-09-30 16:30 +0200
    [PATCH 12/45] perf tools: Add stat event read function Jiri Olsa <jolsa@kernel.org> - 2015-09-30 16:30 +0200
    [PATCH 02/45] perf tools: Add thread_map event synthesize function Jiri Olsa <jolsa@kernel.org> - 2015-09-30 16:30 +0200
    [PATCH 14/45] perf tools: Add stat round event synthesize function Jiri Olsa <jolsa@kernel.org> - 2015-09-30 16:30 +0200
    [PATCH 15/45] perf tools: Introduce stat feature Jiri Olsa <jolsa@kernel.org> - 2015-09-30 16:30 +0200
    [PATCH 04/45] perf tools: Add cpu_map event Jiri Olsa <jolsa@kernel.org> - 2015-09-30 16:30 +0200
    [PATCH 22/45] perf stat record: Store events IDs in perf data file Jiri Olsa <jolsa@kernel.org> - 2015-09-30 16:30 +0200
    [PATCH 08/45] perf tools: Add stat config event synthesize function Jiri Olsa <jolsa@kernel.org> - 2015-09-30 16:30 +0200
    [PATCH 19/45] perf stat record: Add record command Jiri Olsa <jolsa@kernel.org> - 2015-09-30 16:30 +0200
    [PATCH 21/45] perf stat record: Synthesize stat record data Jiri Olsa <jolsa@kernel.org> - 2015-09-30 16:30 +0200
    RE: [PATCHv2 00/45] perf stat: Add scripting support "Liang, Kan" <kan.liang@intel.com> - 2015-09-30 23:20 +0200
      Re: [PATCHv2 00/45] perf stat: Add scripting support Jiri Olsa <jolsa@redhat.com> - 2015-09-30 23:40 +0200
      Re: [PATCHv2 00/45] perf stat: Add scripting support Jiri Olsa <jolsa@redhat.com> - 2015-09-30 23:40 +0200

Page 2 of 2 — ← Prev page 1 [2]


#1236400 — [PATCH 21/45] perf stat record: Synthesize stat record data

FromJiri Olsa <jolsa@kernel.org>
Date2015-09-30 16:30 +0200
Subject[PATCH 21/45] perf stat record: Synthesize stat record data
Message-ID<qeqyn-7BV-47@gated-at.bofh.it>
In reply to#1236373
Synthesizing needed stat record data for report/script:
  - cpu/thread maps
  - stat config

Link: http://lkml.kernel.org/n/tip-wni1s2i2sq17g4vomjyda2yf@git.kernel.org
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
---
 tools/perf/builtin-stat.c | 47 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 47 insertions(+)

diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index a81896b2307b..fa5299db0d2d 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -191,6 +191,20 @@ static inline int nsec_counter(struct perf_evsel *evsel)
 	return 0;
 }
 
+static int process_synthesized_event(struct perf_tool *tool __maybe_unused,
+				     union perf_event *event,
+				     struct perf_sample *sample __maybe_unused,
+				     struct machine *machine __maybe_unused)
+{
+	if (perf_data_file__write(&perf_stat.file, event, event->header.size) < 0) {
+		pr_err("failed to write perf data, error: %m\n");
+		return -1;
+	}
+
+	perf_stat.bytes_written += event->header.size;
+	return 0;
+}
+
 /*
  * Read out the results of a single counter:
  * do not aggregate counts across CPUs in system-wide mode
@@ -277,6 +291,35 @@ static void workload_exec_failed_signal(int signo __maybe_unused, siginfo_t *inf
 	workload_exec_errno = info->si_value.sival_int;
 }
 
+static int perf_stat_synthesize_config(void)
+{
+	int err;
+
+	err = perf_event__synthesize_thread_map2(NULL, evsel_list->threads,
+						process_synthesized_event,
+						NULL);
+	if (err < 0) {
+		pr_err("Couldn't synthesize thread map.\n");
+		return err;
+	}
+
+	err = perf_event__synthesize_cpu_map(NULL, evsel_list->cpus,
+					     process_synthesized_event, NULL);
+	if (err < 0) {
+		pr_err("Couldn't synthesize thread map.\n");
+		return err;
+	}
+
+	err = perf_event__synthesize_stat_config(NULL, &stat_config,
+						 process_synthesized_event, NULL);
+	if (err < 0) {
+		pr_err("Couldn't synthesize config.\n");
+		return err;
+	}
+
+	return 0;
+}
+
 static int __run_perf_stat(int argc, const char **argv)
 {
 	int interval = stat_config.interval;
@@ -357,6 +400,10 @@ static int __run_perf_stat(int argc, const char **argv)
 						 fd, false);
 		if (err < 0)
 			return err;
+
+		err = perf_stat_synthesize_config();
+		if (err < 0)
+			return err;
 	}
 
 	/*
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1236765

From"Liang, Kan" <kan.liang@intel.com>
Date2015-09-30 23:20 +0200
Message-ID<qewX8-8qQ-9@gated-at.bofh.it>
In reply to#1236373
> hi,
> sending another version of stat scripting.
> 
> v2 changes:
>   - rebased to latest Arnaldo's perf/core
>   - patches 1 to 11 already merged in
>   - added --per-core/--per-socket/-A options for perf stat report
>     command to allow custom aggregation in stat report, please
>     check new examples below
>   - couple changelogs changes
> 
> The initial attempt defined its own formula lang and allowed triggering
> user's script on the end of the stat command:
>   http://marc.info/?l=linux-kernel&m=136742146322273&w=2
> 
> This patchset abandons the idea of new formula language and rather adds
> support to:
>   - store stat data into perf.data file
>   - add python support to process stat events
> 
> Basically it allows to store stat data into perf.data and post process it with
> python scripts in a similar way we do for sampling data.
> 
> The stat data are stored in new stat, stat-round, stat-config user events.
>   stat        - stored for each read syscall of the counter
>   stat round  - stored for each interval or end of the command invocation
>   stat config - stores all the config information needed to process data
>                 so report tool could restore the same output as record
> 
> The python script can now define 'stat__<eventname>_<modifier>'
> functions to get stat events data and 'stat__interval' to get stat-round data.
> 
> See CPI script example in scripts/python/stat-cpi.py.
> 
> Also available in:
>   git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git
>   perf/stat_script
> 
> thanks,
> jirka
> 
> 
> Examples:
> 
> - To record data for command stat workload:
> 
>   $ perf stat record kill
>   ...
> 
>    Performance counter stats for 'kill':
> 
>             0.372007      task-clock (msec)         #    0.613 CPUs utilized
>                    3      context-switches          #    0.008 M/sec
>                    0      cpu-migrations            #    0.000 K/sec
>                   62      page-faults               #    0.167 M/sec
>            1,129,973      cycles                    #    3.038 GHz
>      <not supported>      stalled-cycles-frontend
>      <not supported>      stalled-cycles-backend
>              813,313      instructions              #    0.72  insns per cycle
>              166,161      branches                  #  446.661 M/sec
>                8,747      branch-misses             #    5.26% of all branches
> 
>          0.000607287 seconds time elapsed
> 

The default file for perf stat record is perf.data.
It's easy to be mix up with the data file from perf record.
How about using perf.data.stat to instead?


> - To report perf stat data:
> 
>   $ perf stat report
> 
>    Performance counter stats for '/home/jolsa/bin/perf stat record kill':
> 
>             0.372007      task-clock (msec)         #      inf CPUs utilized
>                    3      context-switches          #    0.008 M/sec
>                    0      cpu-migrations            #    0.000 K/sec
>                   62      page-faults               #    0.167 M/sec
>            1,129,973      cycles                    #    3.038 GHz
>      <not supported>      stalled-cycles-frontend
>      <not supported>      stalled-cycles-backend
>              813,313      instructions              #    0.72  insns per cycle
>              166,161      branches                  #  446.661 M/sec
>                8,747      branch-misses             #    5.26% of all branches
> 
>          0.000000000 seconds time elapsed
> 
> - To store system-wide period stat data:
> 
>   $ perf stat -e cycles:u,instructions:u -a -I 1000 record
>   #           time             counts unit events
>        1.000265471        462,311,482      cycles:u                   (100.00%)
>        1.000265471        590,037,440      instructions:u
>        2.000483453        722,532,336      cycles:u                   (100.00%)
>        2.000483453        848,678,197      instructions:u
>        3.000759876         75,990,880      cycles:u                   (100.00%)
>        3.000759876         86,187,813      instructions:u
>   ^C     3.213960893         85,329,533      cycles:u                   (100.00%)
>        3.213960893        135,954,296      instructions:u
> 
> - To report perf stat data:
>

Could we support perf report as well?
If I run perf report with the data file, there are some warnings.
We know the data file is from perf stat or perf record, so it should
be not hard to handle the warnings.
Also it's better that all the new record type (CPU/THREAD_MAP,
STAT_CONFIG, STAT and etc) can be dumped by perf report -D.
It shows unhandled now.

>   $ perf stat report
>   #           time             counts unit events
>        1.000265471        462,311,482      cycles:u                   (100.00%)
>        1.000265471        590,037,440      instructions:u
>        2.000483453        722,532,336      cycles:u                   (100.00%)
>        2.000483453        848,678,197      instructions:u
>        3.000759876         75,990,880      cycles:u                   (100.00%)
>        3.000759876         86,187,813      instructions:u
>        3.213960893         85,329,533      cycles:u                   (100.00%)
>        3.213960893        135,954,296      instructions:u
> 
> - To run stat-cpi.py script over perf.data:
> 
>   $ perf script -s scripts/python/stat-cpi.py
>          1.000265: cpu -1, thread -1 -> cpi 0.783529 (462311482/590037440)
>          2.000483: cpu -1, thread -1 -> cpi 0.851362 (722532336/848678197)
>          3.000760: cpu -1, thread -1 -> cpi 0.881689 (75990880/86187813)
>          3.213961: cpu -1, thread -1 -> cpi 0.627634 (85329533/135954296)
> 
> - To pipe data from stat to stat-cpi script:
> 
>   $ perf stat -e cycles:u,instructions:u -A -C 0 -I 1000 record | perf script -s
> scripts/python/stat-cpi.py
>          1.000192: cpu 0, thread -1 -> cpi 0.739535 (23921908/32347236)
>          2.000376: cpu 0, thread -1 -> cpi 1.663482 (2519340/1514498)
>          3.000621: cpu 0, thread -1 -> cpi 1.396308 (16162767/11575362)
>          4.000700: cpu 0, thread -1 -> cpi 1.092246 (20077258/18381624)
>          5.000867: cpu 0, thread -1 -> cpi 0.473816 (45157586/95306156)
>          6.001034: cpu 0, thread -1 -> cpi 0.532792 (43701668/82023818)
>          7.001195: cpu 0, thread -1 -> cpi 1.122059 (29890042/26638561)
> 
> - Raw script stat data output:
> 
>   $ perf stat -e cycles:u,instructions:u -A -C 0 -I 1000 record | perf --no-
> pager script
>   CPU   THREAD             VAL             ENA             RUN            TIME EVENT
>     0       -1        12302059      1000811347      1000810712      1000198821 cycles:u
>     0       -1         2565362      1000823218      1000823218      1000198821
> instructions:u
>     0       -1        14453353      1000812704      1000812704      2000382283 cycles:u
>     0       -1         4600932      1000799342      1000799342      2000382283
> instructions:u
>     0       -1        15245106      1000774425      1000774425      3000538255 cycles:u
>     0       -1         2624324      1000769310      1000769310      3000538255
> instructions:u
> 
> - To display different aggregation in report:
> 


This one doesn't work well with uncore event.

sudo ./perf stat -e uncore_imc_1/cas_count_read/ -a --per-socket record 
-- sleep 5                   
 Performance counter stats for 'system wide':

S0        1               0.87 MiB  uncore_imc_1/cas_count_read/
S1        1               0.41 MiB  uncore_imc_1/cas_count_read/

       5.000910939 seconds time elapsed

sudo ./perf stat report --per-socket

 Performance counter stats for '/home/lk/group_read/test/perf/tools/
perf/perf stat -e uncore_imc_1/cas_count_read/ -a --per-socket record 
-- sleep 5':

S0       36             20,973      uncore_imc_1/cas_count_read/
S1       28      <not counted>      uncore_imc_1/cas_count_read/

       5.000910939 seconds time elapsed

>   $ perf stat -e cycles -a -I 1000 record sleep 3
>   #           time             counts unit events
>        1.000223609        703,427,617      cycles
>        2.000443651        609,975,307      cycles
>        3.000569616        668,479,597      cycles
>        3.000735323          1,155,816      cycles
> 
>   $ perf stat report
>   #           time             counts unit events
>        1.000223609        703,427,617      cycles
>        2.000443651        609,975,307      cycles
>        3.000569616        668,479,597      cycles
>        3.000735323          1,155,816      cycles
> 
>   $ perf stat report --per-core
>   #           time core         cpus             counts unit events
>        1.000223609 S0-C0           2        327,612,412      cycles
>        1.000223609 S0-C1           2        375,815,205      cycles
>        2.000443651 S0-C0           2        287,462,177      cycles
>        2.000443651 S0-C1           2        322,513,130      cycles
>        3.000569616 S0-C0           2        271,571,908      cycles
>        3.000569616 S0-C1           2        396,907,689      cycles
>        3.000735323 S0-C0           2            694,977      cycles
>        3.000735323 S0-C1           2            460,839      cycles
> 
>   $ perf stat report --per-socket
>   #           time socket cpus             counts unit events
>        1.000223609 S0        4        703,427,617      cycles
>        2.000443651 S0        4        609,975,307      cycles
>        3.000569616 S0        4        668,479,597      cycles
>        3.000735323 S0        4          1,155,816      cycles
> 
>   $ perf stat report -A
>   #           time CPU                counts unit events
>        1.000223609 CPU0           205,431,505      cycles
>        1.000223609 CPU1           122,180,907      cycles
>        1.000223609 CPU2           176,649,682      cycles
>        1.000223609 CPU3           199,165,523      cycles
>        2.000443651 CPU0           148,447,922      cycles
>        2.000443651 CPU1           139,014,255      cycles
>        2.000443651 CPU2           204,436,559      cycles
>        2.000443651 CPU3           118,076,571      cycles
>        3.000569616 CPU0           149,788,954      cycles
>        3.000569616 CPU1           121,782,954      cycles
>        3.000569616 CPU2           247,277,700      cycles
>        3.000569616 CPU3           149,629,989      cycles
>        3.000735323 CPU0               269,675      cycles
>        3.000735323 CPU1               425,302      cycles
>        3.000735323 CPU2               364,169      cycles
>        3.000735323 CPU3                96,670      cycles
> 
> 
> Cc: Andi Kleen <andi@firstfloor.org>
> Cc: Ulrich Drepper <drepper@gmail.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Stephane Eranian <eranian@google.com>
> Cc: Don Zickus <dzickus@redhat.com>
> ---
> Jiri Olsa (45):
>       perf tools: Add thread_map event
>       perf tools: Add thread_map event sythesize function
>       perf tools: Add thread_map__new_event function
>       perf tools: Add cpu_map event
>       perf tools: Add cpu_map event synthesize function
>       perf tools: Add cpu_map__new_event function
>       perf tools: Add stat config event
>       perf tools: Add stat config event synthesize function
>       perf tools: Add stat config event read function
>       perf tools: Add stat event
>       perf tools: Add stat event synthesize function
>       perf tools: Add stat event read function
>       perf tools: Add stat round event
>       perf tools: Add stat round event synthesize function
>       perf tools: Introduce stat feature
>       perf tools: Move id_offset out of struct perf_evsel union
>       perf stat: Rename perf_stat struct into perf_stat_evsel
>       perf stat: Add AGGR_UNSET mode
>       perf stat record: Add record command
>       perf stat record: Initialize record features
>       perf stat record: Synthesize stat record data
>       perf stat record: Store events IDs in perf data file
>       perf stat record: Add pipe support for record command
>       perf stat record: Write stat events on record
>       perf stat record: Write stat round events on record
>       perf stat record: Do not allow record with multiple runs mode
>       perf tools: Add cpu_map__empty_new interface
>       perf tools: Make cpu_map__build_map global
>       perf tools: Add data arg to cpu_map__build_map callback
>       perf stat report: Cache aggregated map entries in extra cpumap
>       perf stat report: Add report command
>       perf stat report: Process cpu/threads maps
>       perf stat report: Process stat config event
>       perf stat report: Add support to initialize aggr_map from file
>       perf stat report: Process stat and stat round events
>       perf stat report: Move csv_sep initialization before report command
>       perf stat report: Allow to override aggr_mode
>       perf script: Check output fields only for samples
>       perf script: Process cpu/threads maps
>       perf script: Process stat config event
>       perf script: Add process_stat/process_stat_interval scripting interface
>       perf script: Add stat default handlers
>       perf script: Display stat events by default
>       perf script: Add python support for stat events
>       perf script: Add stat-cpi.py script
> 
>  tools/perf/Documentation/perf-stat.txt                 |  34 ++++++
>  tools/perf/builtin-record.c                            |   2 +
>  tools/perf/builtin-script.c                            | 144
> +++++++++++++++++++++++-
>  tools/perf/builtin-stat.c                              | 584
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> ++++++++++++++++++++++++++++++++++++---
>  tools/perf/scripts/python/stat-cpi.py                  |  74 +++++++++++++
>  tools/perf/tests/Build                                 |   2 +
>  tools/perf/tests/builtin-test.c                        |  21 ++++
>  tools/perf/tests/cpumap.c                              |  39 +++++++
>  tools/perf/tests/stat.c                                | 111 +++++++++++++++++++
>  tools/perf/tests/tests.h                               |   6 +
>  tools/perf/tests/thread-map.c                          |  43 +++++++
>  tools/perf/tests/topology.c                            |   4 +-
>  tools/perf/util/cpumap.c                               |  61 ++++++++--
>  tools/perf/util/cpumap.h                               |  11 +-
>  tools/perf/util/event.c                                | 172
> ++++++++++++++++++++++++++++
>  tools/perf/util/event.h                                | 100 ++++++++++++++++-
>  tools/perf/util/evlist.c                               |   6 +-
>  tools/perf/util/evlist.h                               |   3 +
>  tools/perf/util/evsel.h                                |   2 +-
>  tools/perf/util/header.c                               |  14 +++
>  tools/perf/util/header.h                               |   1 +
>  tools/perf/util/scripting-engines/trace-event-python.c | 114
> ++++++++++++++++++-
>  tools/perf/util/session.c                              | 123 +++++++++++++++++++++
>  tools/perf/util/stat.c                                 |  36 +++++-
>  tools/perf/util/stat.h                                 |   9 +-
>  tools/perf/util/thread_map.c                           |  27 +++++
>  tools/perf/util/thread_map.h                           |   3 +
>  tools/perf/util/tool.h                                 |   7 +-
>  tools/perf/util/trace-event.h                          |   4 +
>  29 files changed, 1708 insertions(+), 49 deletions(-)  create mode 100644
> tools/perf/scripts/python/stat-cpi.py
>  create mode 100644 tools/perf/tests/cpumap.c  create mode 100644
> tools/perf/tests/stat.c
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1236787

FromJiri Olsa <jolsa@redhat.com>
Date2015-09-30 23:40 +0200
Message-ID<qexgu-oR-29@gated-at.bofh.it>
In reply to#1236765
On Wed, Sep 30, 2015 at 09:09:39PM +0000, Liang, Kan wrote:

SNIP

> > instructions:u
> > 
> > - To display different aggregation in report:
> > 
> 
> 
> This one doesn't work well with uncore event.
> 
> sudo ./perf stat -e uncore_imc_1/cas_count_read/ -a --per-socket record 
> -- sleep 5                   
>  Performance counter stats for 'system wide':
> 
> S0        1               0.87 MiB  uncore_imc_1/cas_count_read/
> S1        1               0.41 MiB  uncore_imc_1/cas_count_read/
> 
>        5.000910939 seconds time elapsed
> 
> sudo ./perf stat report --per-socket
> 
>  Performance counter stats for '/home/lk/group_read/test/perf/tools/
> perf/perf stat -e uncore_imc_1/cas_count_read/ -a --per-socket record 
> -- sleep 5':
> 
> S0       36             20,973      uncore_imc_1/cas_count_read/
> S1       28      <not counted>      uncore_imc_1/cas_count_read/

hum, looks like there's some issue with unit/scale handling

I'll address that in next version

thanks for fast feedback,
jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1236788

FromJiri Olsa <jolsa@redhat.com>
Date2015-09-30 23:40 +0200
Message-ID<qexgu-oR-31@gated-at.bofh.it>
In reply to#1236765
On Wed, Sep 30, 2015 at 09:09:39PM +0000, Liang, Kan wrote:

SNIP

> > Examples:
> > 
> > - To record data for command stat workload:
> > 
> >   $ perf stat record kill
> >   ...
> > 
> >    Performance counter stats for 'kill':
> > 
> >             0.372007      task-clock (msec)         #    0.613 CPUs utilized
> >                    3      context-switches          #    0.008 M/sec
> >                    0      cpu-migrations            #    0.000 K/sec
> >                   62      page-faults               #    0.167 M/sec
> >            1,129,973      cycles                    #    3.038 GHz
> >      <not supported>      stalled-cycles-frontend
> >      <not supported>      stalled-cycles-backend
> >              813,313      instructions              #    0.72  insns per cycle
> >              166,161      branches                  #  446.661 M/sec
> >                8,747      branch-misses             #    5.26% of all branches
> > 
> >          0.000607287 seconds time elapsed
> > 
> 
> The default file for perf stat record is perf.data.
> It's easy to be mix up with the data file from perf record.
> How about using perf.data.stat to instead?

hum, I'm inclined to keep using the perf.data as default
of whatever comes out of the perf.. and do the 'perf report'
proxy based on the data you described in the next comment

SNIP

> > - To store system-wide period stat data:
> > 
> >   $ perf stat -e cycles:u,instructions:u -a -I 1000 record
> >   #           time             counts unit events
> >        1.000265471        462,311,482      cycles:u                   (100.00%)
> >        1.000265471        590,037,440      instructions:u
> >        2.000483453        722,532,336      cycles:u                   (100.00%)
> >        2.000483453        848,678,197      instructions:u
> >        3.000759876         75,990,880      cycles:u                   (100.00%)
> >        3.000759876         86,187,813      instructions:u
> >   ^C     3.213960893         85,329,533      cycles:u                   (100.00%)
> >        3.213960893        135,954,296      instructions:u
> > 
> > - To report perf stat data:
> >
> 
> Could we support perf report as well?
> If I run perf report with the data file, there are some warnings.
> We know the data file is from perf stat or perf record, so it should
> be not hard to handle the warnings.

well perf report wants to display sampling data which are
not present.. probabbly complaining about sample_type I guess

I think 'perf report' could check on perf.data and if it
detects stat data proxy the handling to the perf stat report

but not sure how to handle both commands options differencies ATM

> Also it's better that all the new record type (CPU/THREAD_MAP,
> STAT_CONFIG, STAT and etc) can be dumped by perf report -D.
> It shows unhandled now.

right, I'll those

thanks,
jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]


Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel


csiph-web