From: Namhyung Kim <namhyung@kernel.org>
To: Stephane Eranian <eranian@google.com>
Cc: linux-kernel@vger.kernel.org, peterz@infradead.org,
mingo@elte.hu, ak@linux.intel.com, acme@redhat.com,
jolsa@redhat.com, ming.m.lin@intel.com
Subject: Re: [Patch v1 10/10] perf tools: add new mem command for memory access profiling
Date: Wed, 31 Oct 2012 15:57:57 +0900 [thread overview]
Message-ID: <87a9v35dsa.fsf@sejong.aot.lge.com> (raw)
In-Reply-To: <1351523752-4215-11-git-send-email-eranian@google.com> (Stephane Eranian's message of "Mon, 29 Oct 2012 16:15:52 +0100")
On Mon, 29 Oct 2012 16:15:52 +0100, Stephane Eranian wrote:
> This new command is a wrapper on top of perf record and
> perf report to make it easier to configure for memory
> access profiling.
So this new command will be run only on speicific (PEBS > 2?) Intel
machines, right? Is there anything we can do for others? Or at least
it might emit a warning message..
>
> To record loads:
> $ perf mem -t load rec .....
>
> To record stores:
> $ perf mem -t store rec .....
>
> To get the report:
> $ perf mem -t load rep
>
> Signed-off-by: Stephane Eranian <eranian@google.com>
> ---
[snip]
> +perf-mem(1)
> +===========
> +
> +NAME
> +----
> +perf-mem - Profile memory accesses
> +
> +SYNOPSIS
> +--------
> +[verse]
> +'perf mem' -t load record <command>
> +'perf mem' -t store record <command>
> +'perf mem' -t load report
> +'perf mem' -t store report
Is '-t' option mandatory? AFAISC it seems optional and defaults to load.
And is <command> for record also mandatory? Doesn't 'perf record' make
it optional?
If so, the above can be written like you did in 'mem_usage':
'perf mem' [<options>] (record [<command>] | report)
> +
> +DESCRIPTION
> +-----------
> +"perf mem -t <TYPE> record" runs a command and gathers memory operation data
> +from it, into perf.data. Perf record options are accepted and are passed through.
> +
> +"perf mem -t <TYPE> report" displays the result. It invokes perf report with the
> +right set of options to display a memory access profile.
> +
> +OPTIONS
> +-------
> +<command>...::
> + Any command you can specify in a shell.
> +
> +-t::
> +--type=::
> + Select the memory operation type: load or store
It'd better saying it defaults to load.
> +
> +-R::
> +--dump-raw-samples=::
> + Dump the raw decoded samples on the screen in a format that is easy to parse with
> + one sample per line.
Didn't we usually use -D switch for this?
> +
> +-x::
> +--field-separator::
> + Specify the field separator used when dump raw samples (-R option). By default,
> + The separator is the space character.
And using -t for this will make it consistent with perf report IMHO.
> +
> +-C::
> +--cpu-list::
> + Restrict dump of raw samples to those provided via this option. Note that the same
> + option can be passed in record mode. It will be interpreted the same way as perf
> + record.
> +
> +SEE ALSO
> +--------
> +linkperf:perf-record[1], linkperf:perf-report[1]
[snip]
> +#define MEM_OPERATION_LOAD "load"
> +#define MEM_OPERATION_STORE "store"
> +
> +static char const *input_name = "perf.data";
We have a global 'input_name' as of commit 70cb4e963f77 ("perf tools:
Add a global variable 'const char *input_name'").
> +static const char *mem_operation = MEM_OPERATION_LOAD;
> +static const char *csv_sep = NULL;
Why not use symbol_conf.field_sep?
> +
> +struct perf_mem {
> + struct perf_tool tool;
> + char const *input_name;
> + symbol_filter_t annotate_init;
> + bool hide_unresolved;
> + bool dump_raw;
> + const char *cpu_list;
> + DECLARE_BITMAP(cpu_bitmap, MAX_NR_CPUS);
> +};
> +
> +static const char * const mem_usage[] = {
> + "perf mem [<options>] {record <command> |report}",
> + NULL
> +};
[snip]
> +static int report_raw_events(struct perf_mem *mem)
> +{
> + int err = -EINVAL;
> + int ret;
> + struct perf_session *session = perf_session__new(input_name, O_RDONLY,
> + 0, false, &mem->tool);
> +
> + if (mem->cpu_list) {
> + ret = perf_session__cpu_bitmap(session, mem->cpu_list,
> + mem->cpu_bitmap);
> + if (ret)
> + goto out_delete;
> + }
> +
> + if (symbol__init() < 0)
> + return -1;
> +
> + if (session == NULL)
> + return -ENOMEM;
This check should be moved before perf_session__cpu_bitmap() calls.
Thanks,
Namhyung
> +
> + printf("# PID, TID, IP, ADDR, COST, DSRC, SYMBOL\n");
> +
> + err = perf_session__process_events(session, &mem->tool);
> + if (err)
> + return err;
> +
> + return 0;
> +
> +out_delete:
> + perf_session__delete(session);
> + return err;
> +}
next prev parent reply other threads:[~2012-10-31 6:58 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-29 15:15 [Patch v1 00/10] perf: add memory access sampling support Stephane Eranian
2012-10-29 15:15 ` [Patch v1 01/10] perf/x86: improve sysfs event mapping with event string Stephane Eranian
2012-10-29 19:25 ` Andi Kleen
2012-10-29 15:15 ` [Patch v1 02/10] perf/x86: add flags to event constraints Stephane Eranian
2012-10-29 15:15 ` [Patch v1 03/10] perf: add generic memory sampling interface Stephane Eranian
2012-10-29 15:15 ` [Patch v1 04/10] perf/x86: add memory profiling via PEBS Load Latency Stephane Eranian
2012-10-29 15:23 ` Peter Zijlstra
2012-10-29 15:24 ` Stephane Eranian
2012-10-29 15:35 ` Peter Zijlstra
2012-10-29 15:39 ` Stephane Eranian
2012-10-29 15:38 ` Peter Zijlstra
2012-10-29 15:43 ` Stephane Eranian
2012-10-29 15:44 ` Peter Zijlstra
2012-10-29 19:42 ` Andi Kleen
2012-10-29 20:39 ` Stephane Eranian
2012-10-29 20:44 ` Peter Zijlstra
2012-10-29 21:16 ` Andi Kleen
2012-10-29 21:32 ` Stephane Eranian
2012-10-29 21:56 ` Andi Kleen
2012-10-30 8:43 ` Namhyung Kim
2012-10-29 15:15 ` [Patch v1 05/10] perf/x86: export PEBS load latency threshold register to sysfs Stephane Eranian
2012-10-29 15:15 ` [Patch v1 06/10] perf/x86: add support for PEBS Precise Store Stephane Eranian
2012-10-29 15:40 ` Peter Zijlstra
2012-10-29 15:44 ` Stephane Eranian
2012-10-31 5:21 ` Namhyung Kim
2012-10-31 13:28 ` Stephane Eranian
2012-10-29 15:15 ` [Patch v1 07/10] perf tools: add mem access sampling core support Stephane Eranian
2012-10-29 16:55 ` Andi Kleen
2012-10-29 17:00 ` Stephane Eranian
2012-10-31 5:51 ` Namhyung Kim
2012-10-31 13:30 ` Stephane Eranian
2012-10-29 15:15 ` [Patch v1 08/10] perf report: add support for mem access profiling Stephane Eranian
2012-10-31 6:01 ` Namhyung Kim
2012-10-29 15:15 ` [Patch v1 09/10] perf record: " Stephane Eranian
2012-10-29 15:15 ` [Patch v1 10/10] perf tools: add new mem command for memory " Stephane Eranian
2012-10-31 6:57 ` Namhyung Kim [this message]
2012-10-31 14:23 ` Stephane Eranian
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=87a9v35dsa.fsf@sejong.aot.lge.com \
--to=namhyung@kernel.org \
--cc=acme@redhat.com \
--cc=ak@linux.intel.com \
--cc=eranian@google.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ming.m.lin@intel.com \
--cc=mingo@elte.hu \
--cc=peterz@infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.