From: Jiri Olsa <jolsa@redhat.com>
To: kan.liang@linux.intel.com
Cc: acme@kernel.org, mingo@kernel.org, linux-kernel@vger.kernel.org,
namhyung@kernel.org, eranian@google.com, ak@linux.intel.com,
mark.rutland@arm.com, will@kernel.org, mpe@ellerman.id.au
Subject: Re: [PATCH V2 06/12] perf mem: Clean up output format
Date: Sat, 5 Dec 2020 00:27:56 +0100 [thread overview]
Message-ID: <20201204232756.GK3613628@krava> (raw)
In-Reply-To: <20201130172803.2676-7-kan.liang@linux.intel.com>
On Mon, Nov 30, 2020 at 09:27:57AM -0800, kan.liang@linux.intel.com wrote:
SNIP
> @@ -172,7 +172,7 @@ dump_raw_samples(struct perf_tool *tool,
> {
> struct perf_mem *mem = container_of(tool, struct perf_mem, tool);
> struct addr_location al;
> - const char *fmt;
> + const char *fmt, *field_sep;
>
> if (machine__resolve(machine, &al, sample) < 0) {
> fprintf(stderr, "problem processing %d event, skipping it.\n",
> @@ -186,60 +186,41 @@ dump_raw_samples(struct perf_tool *tool,
> if (al.map != NULL)
> al.map->dso->hit = 1;
>
> - if (mem->phys_addr) {
> - if (symbol_conf.field_sep) {
> - fmt = "%d%s%d%s0x%"PRIx64"%s0x%"PRIx64"%s0x%016"PRIx64
> - "%s%"PRIu64"%s0x%"PRIx64"%s%s:%s\n";
> - } else {
> - fmt = "%5d%s%5d%s0x%016"PRIx64"%s0x016%"PRIx64
> - "%s0x%016"PRIx64"%s%5"PRIu64"%s0x%06"PRIx64
> - "%s%s:%s\n";
> - symbol_conf.field_sep = " ";
> - }
> -
> - printf(fmt,
> - sample->pid,
> - symbol_conf.field_sep,
> - sample->tid,
> - symbol_conf.field_sep,
> - sample->ip,
> - symbol_conf.field_sep,
> - sample->addr,
> - symbol_conf.field_sep,
> - sample->phys_addr,
> - symbol_conf.field_sep,
> - sample->weight,
> - symbol_conf.field_sep,
> - sample->data_src,
> - symbol_conf.field_sep,
> - al.map ? (al.map->dso ? al.map->dso->long_name : "???") : "???",
> - al.sym ? al.sym->name : "???");
> + field_sep = symbol_conf.field_sep;
hum, what's the point of having field_sep?
> + if (field_sep) {
> + fmt = "%d%s%d%s0x%"PRIx64"%s0x%"PRIx64"%s";
> } else {
> - if (symbol_conf.field_sep) {
> - fmt = "%d%s%d%s0x%"PRIx64"%s0x%"PRIx64"%s%"PRIu64
> - "%s0x%"PRIx64"%s%s:%s\n";
> - } else {
> - fmt = "%5d%s%5d%s0x%016"PRIx64"%s0x016%"PRIx64
> - "%s%5"PRIu64"%s0x%06"PRIx64"%s%s:%s\n";
> - symbol_conf.field_sep = " ";
> - }
> + fmt = "%5d%s%5d%s0x%016"PRIx64"%s0x016%"PRIx64"%s";
> + symbol_conf.field_sep = " ";
> + }
> + printf(fmt,
> + sample->pid,
> + symbol_conf.field_sep,
> + sample->tid,
> + symbol_conf.field_sep,
> + sample->ip,
> + symbol_conf.field_sep,
> + sample->addr,
> + symbol_conf.field_sep);
>
> - printf(fmt,
> - sample->pid,
> - symbol_conf.field_sep,
> - sample->tid,
> - symbol_conf.field_sep,
> - sample->ip,
> - symbol_conf.field_sep,
> - sample->addr,
> - symbol_conf.field_sep,
> - sample->weight,
> - symbol_conf.field_sep,
> - sample->data_src,
> - symbol_conf.field_sep,
> - al.map ? (al.map->dso ? al.map->dso->long_name : "???") : "???",
> - al.sym ? al.sym->name : "???");
> + if (mem->phys_addr) {
> + printf("0x%016"PRIx64"%s",
> + sample->phys_addr,
> + symbol_conf.field_sep);
> }
> +
> + if (field_sep)
> + fmt = "%"PRIu64"%s0x%"PRIx64"%s%s:%s\n";
> + else
> + fmt = "%5"PRIu64"%s0x%06"PRIx64"%s%s:%s\n";
> +
> + printf(fmt,
> + sample->weight,
> + symbol_conf.field_sep,
> + sample->data_src,
> + symbol_conf.field_sep,
> + al.map ? (al.map->dso ? al.map->dso->long_name : "???") : "???",
> + al.sym ? al.sym->name : "???");
> out_put:
> addr_location__put(&al);
> return 0;
> @@ -287,10 +268,12 @@ static int report_raw_events(struct perf_mem *mem)
> if (ret < 0)
> goto out_delete;
>
> + printf("# PID, TID, IP, ADDR, ");
> +
> if (mem->phys_addr)
> - printf("# PID, TID, IP, ADDR, PHYS ADDR, LOCAL WEIGHT, DSRC, SYMBOL\n");
> - else
> - printf("# PID, TID, IP, ADDR, LOCAL WEIGHT, DSRC, SYMBOL\n");
> + printf("PHYS ADDR, ");
> +
> + printf("LOCAL WEIGHT, DSRC, SYMBOL\n");
if phys addr is the only member, can't we just squeeze it via
"%s", mem->phys_addr ? "PHYS ADDR" : "",
like I mentioned in the other reply? and same also above?
thanks,
jirka
>
> ret = perf_session__process_events(session);
>
> --
> 2.17.1
>
next prev parent reply other threads:[~2020-12-04 23:31 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-30 17:27 [PATCH V2 00/12] Add the page size in the perf record (user tools) kan.liang
2020-11-30 17:27 ` [PATCH V2 01/12] tools headers UAPI: Update tools's copy of linux/perf_event.h kan.liang
2020-12-07 16:52 ` Arnaldo Carvalho de Melo
2020-11-30 17:27 ` [PATCH V2 02/12] perf record: Support new sample type for data page size kan.liang
2020-12-07 17:07 ` Arnaldo Carvalho de Melo
2020-12-07 20:25 ` Liang, Kan
2020-12-16 15:49 ` Arnaldo Carvalho de Melo
2020-11-30 17:27 ` [PATCH V2 03/12] perf script: Support " kan.liang
2020-12-04 23:27 ` Jiri Olsa
2020-11-30 17:27 ` [PATCH V2 04/12] perf sort: Add sort option for " kan.liang
2020-11-30 17:27 ` [PATCH V2 05/12] perf mem: Factor out a function to generate sort order kan.liang
2020-12-04 23:27 ` Jiri Olsa
2020-11-30 17:27 ` [PATCH V2 06/12] perf mem: Clean up output format kan.liang
2020-12-04 23:27 ` Jiri Olsa [this message]
2020-12-07 20:19 ` Liang, Kan
2020-12-08 10:29 ` Jiri Olsa
2020-11-30 17:27 ` [PATCH V2 07/12] perf mem: Support data page size kan.liang
2020-11-30 17:27 ` [PATCH V2 08/12] perf test: Add test case for PERF_SAMPLE_DATA_PAGE_SIZE kan.liang
2020-11-30 17:28 ` [PATCH V2 09/12] perf tools: Add support for PERF_SAMPLE_CODE_PAGE_SIZE kan.liang
2020-11-30 17:28 ` [PATCH V2 10/12] perf script: " kan.liang
2020-11-30 17:28 ` [PATCH V2 11/12] perf report: " kan.liang
2020-11-30 17:28 ` [PATCH V2 12/12] perf test: Add test case " kan.liang
2020-12-08 10:31 ` [PATCH V2 00/12] Add the page size in the perf record (user tools) Jiri Olsa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201204232756.GK3613628@krava \
--to=jolsa@redhat.com \
--cc=acme@kernel.org \
--cc=ak@linux.intel.com \
--cc=eranian@google.com \
--cc=kan.liang@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@kernel.org \
--cc=mpe@ellerman.id.au \
--cc=namhyung@kernel.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).