perf: Introduce branch sub commands

Provide the function to print pid and command name to 'perf branch trace'. Users can select items to print with options. For example,
'perf branch -p trace' prints only pid,
'perf branch -ac trace' prints address and comamnd name. 'perf branch trace' prints only address (default)

This is output sample (perf branch -ac trace):

command      address
ls           0xffffffff8146fe0e => ls           0x0000003806200b20
ls           0xffffffff8146fe0e => ls           0x0000003806200b20
ls           0x0000003806200b23 => ls           0x0000003806204910
ls           0xffffffff8146fe0e => ls           0x0000003806204910
ls           0xffffffff8146fe0e => ls           0x0000003806204936
ls           0xffffffff8146fe0e => ls           0x000000380620493d
ls           0x0000003806204981 => ls           0x00000038062049a3
ls           0x00000038062049a7 => ls           0x0000003806204988

Signed-off-by Akihiro Nagai <[email protected]>

Reviewed-by Masami Hiramatsu <[email protected]>

Cc Peter Zijlstra <[email protected]>

Cc Frederic Weisbecker <[email protected]>

Cc Paul Mackerras <[email protected]>

Cc Ingo Molnar <[email protected]>

Cc Arnaldo Carvalho de Melo <[email protected]>

---

 tools/perf/Documentation/perf-branch.txt |   18 ++++-
 tools/perf/builtin-branch.c              |  119 ++++++++++++++++++++++++++++++
 2 files changed, 133 insertions(+), 4 deletions(-)

tools/perf/Documentation/perf-branch.txt +15 -3

index e223267..6c9c253 100644
@@ -3,7 +3,7 @@ perf-branch(1)
 
 NAME
 ----
-perf-branch - Record and print branch-trace-store log
+perf-branch - Record and analyze branch-trace-store log
 
 SYNOPSIS
 --------

@@ -12,7 +12,7 @@ SYNOPSIS
 
 DESCRIPTION
 -----------
-This command records and prints a branch-trace-store log.
+This command records and analyzes a branch-trace-store log.
 Branch-trace-store is a facility of processors. It can record
 addresses of from/to which the execution of a program branches,
 at every branch instruction and interrupt.

@@ -20,13 +20,25 @@ at every branch instruction and interrupt.
 'perf branch record <command>' records branch-trace-store log while
 the specified command is executing. And, save to the file "perf.data".
 
-'perf branch trace' parses recorded branch-trace-store log and prints it.
+'perf branch trace' analyzes recorded branch-trace-store log and prints it.
+The command can select the item to print. For example,
+  'perf branch -a trace'	: prints only address
+  'perf branch -acp trace'	: prints address, command name and pid
 
 OPTIONS
 -------
 -i::
 --input=::
         Specify input file name to analyze.
+-a::
+--addr::
+	Print address. (default)
+-c::
+--comm::
+	Print command name.
+-p::
+--pid::
+	Print pid.
 
 SEE ALSO
 --------

tools/perf/builtin-branch.c +118 -2

index 7dbabf4..22aa25e 100644
@@ -17,6 +17,32 @@
 /* format string to print address */
 #define FMT_ADDR	"%#0" FMT_ADDR_WIDTH "lx"
 
+/* printable items */
+struct exec_info {
+	u64		addr;		/* recorded address by bts */
+	pid_t		pid;		/* tracee process pid */
+	const char	*comm;		/* command name */
+};
+
+#define EI_PID_UNSET	-1
+
+/* flags which item print */
+#define EI_FLAG_PRINT_ADDR		(1 << 0)
+#define EI_FLAG_PRINT_PID		(1 << 1)
+#define EI_FLAG_PRINT_COMM		(1 << 2)
+
+/* it's used when no print item specified */
+#define EI_FLAG_PRINT_DEFAULT		EI_FLAG_PRINT_ADDR
+
+/* print item flags */
+static unsigned long print_flags;
+
+#define is_flags_unset(flags)		(flags == 0)
+
+/* print it when we cannnot analyze and get the information */
+#define EI_UNKNOWN_TEXT			"(unknown)"
+#define EI_UNKNOWN_TEXT_LEN		(sizeof(EI_UNKNOWN_TEXT))
+
 /* default input file name to analyze */
 static const char *input_name = "perf.data";
 

@@ -34,8 +60,25 @@ static const char * const record_args[] = {
 	"-d",
 };
 
+/* set print flags call from parse_options() */
+static int set_print_flags(const struct option *opt, const char *str __unused,
+							int unset __unused)
+{
+	print_flags |= (unsigned long)opt->defval;
+	return 0;
+}
+
 static const struct option branch_options[] = {
 	OPT_STRING('i', "input", &input_name, "file", "input file name"),
+	OPT_CALLBACK_DEFAULT_NOOPT('a', "addr", NULL, NULL,
+				   "print address (default)", set_print_flags,
+				   (void *)EI_FLAG_PRINT_ADDR),
+	OPT_CALLBACK_DEFAULT_NOOPT('p', "pid", NULL, NULL,
+				   "print pid", set_print_flags,
+				   (void *)EI_FLAG_PRINT_PID),
+	OPT_CALLBACK_DEFAULT_NOOPT('c', "comm", NULL, NULL,
+				   "print command name", set_print_flags,
+				   (void *)EI_FLAG_PRINT_COMM),
 	OPT_END()
 };
 

@@ -60,20 +103,89 @@ static bool is_bts_sample(struct perf_sample *sample,
 	return is_bts_event(evsel);
 }
 
+static void init_exec_info(struct exec_info *ei)
+{
+	memset(ei, 0, sizeof(*ei));
+	ei->pid = EI_PID_UNSET;
+}
+
+/* collect printable items to struct exec_info */
+static void fill_exec_info(struct exec_info *ei,
+		struct perf_session *session, union perf_event *event, u64 addr)
+{
+	struct thread *thread;
+
+	ei->addr = addr;
+	ei->pid = event->ip.pid;
+
+	thread = perf_session__findnew(session, event->ip.pid);
+	if (!thread)
+		return;
+	ei->comm = thread->comm;
+}
+
+static void __print_exec_info(struct exec_info *ei)
+{
+	char pid[16];
+	const char *comm;
+
+	if (print_flags & EI_FLAG_PRINT_PID) {
+		if (ei->pid == EI_PID_UNSET)
+			strncpy(pid, EI_UNKNOWN_TEXT, EI_UNKNOWN_TEXT_LEN);
+		else
+			snprintf(pid, 16, "%d", ei->pid);
+		printf("%5s ", pid);
+	}
+	if (print_flags & EI_FLAG_PRINT_COMM) {
+		comm = ei->comm ? : EI_UNKNOWN_TEXT;
+		printf("%-12s ", comm);
+	}
+	if (print_flags & EI_FLAG_PRINT_ADDR)
+		printf(FMT_ADDR " ", ei->addr);
+}
+
+static void print_exec_info(struct exec_info *ei_from, struct exec_info *ei_to)
+{
+	__print_exec_info(ei_from);
+	printf("=> ");
+	__print_exec_info(ei_to);
+	printf("\n");
+}
+
+static void print_exec_info_header(void)
+{
+	if (print_flags & EI_FLAG_PRINT_PID)
+		printf("%5s ", "pid");
+	if (print_flags & EI_FLAG_PRINT_COMM)
+		printf("%-12s ", "command");
+	if (print_flags & EI_FLAG_PRINT_ADDR)
+		printf("%-" FMT_ADDR_WIDTH "s ", "address");
+	printf("\n");
+}
+
 static int process_sample_event(union perf_event *event __unused,
 		struct perf_sample *sample, struct perf_session *session)
 {
+	struct exec_info ei_from, ei_to;
+
 	if (!is_bts_sample(sample, session))
 		return 0;
 
+	init_exec_info(&ei_from);
+	init_exec_info(&ei_to);
+
 	/* sample->ip is 'from address', sample->addr is 'to address' */
-	printf(FMT_ADDR " => " FMT_ADDR "\n", sample->ip, sample->addr);
+	fill_exec_info(&ei_from, session, event, sample->ip);
+	fill_exec_info(&ei_to, session, event, sample->addr);
+
+	print_exec_info(&ei_from, &ei_to);
 
 	return 0;
 }
 
 static struct perf_event_ops event_ops = {
 	.sample			= process_sample_event,
+	.comm			= perf_event__process_comm,
 	.ordered_samples	= false,
 };
 

@@ -87,7 +199,12 @@ static int __cmd_trace(void)
 		return EXIT_FAILURE;
 	}
 
+	/* if print flags are unset, we use default flags */
+	if (is_flags_unset(print_flags))
+		print_flags = EI_FLAG_PRINT_DEFAULT;
+
 	setup_pager();
+	print_exec_info_header();
 	perf_session__process_events(session, &event_ops);
 	perf_session__delete(session);
 
 
--

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

Quoted 8 lines · Akihiro Nagai

Provide the function to print pid and command name to 'perf branch trace'. Users can select items to print with options. For example,
'perf branch -p trace' prints only pid,
'perf branch -ac trace' prints address and comamnd name. 'perf branch trace' prints only address (default)

This is output sample (perf branch -ac trace):

Quoted 9 lines

command      address
ls           0xffffffff8146fe0e =>  ls           0x0000003806200b20
ls           0xffffffff8146fe0e =>  ls           0x0000003806200b20
ls           0x0000003806200b23 =>  ls           0x0000003806204910
ls           0xffffffff8146fe0e =>  ls           0x0000003806204910
ls           0xffffffff8146fe0e =>  ls           0x0000003806204936
ls           0xffffffff8146fe0e =>  ls           0x000000380620493d
ls           0x0000003806204981 =>  ls           0x00000038062049a3
ls           0x00000038062049a7 =>  ls           0x0000003806204988

This can be easily added to perf-script. e.g,

perf record -e branches:u -c 1 -d -- ls /tmp

perf script -i /tmp/perf.data -f hw:comm,pid,event,sym,addr

...
ls 8150 branches: 0x39d30144d0 ffffffff8146a48e () ls 8150 branches: 0x39d3014507 ffffffff8146a48e ()
ls 8150 branches: 0x39d3014510 14518 _dl_sysdep_start
(/lib64/ld-2.13.so)
...
ls 8150 branches: 0x39d3015250 1833 process_envvars
(/lib64/ld-2.13.so)
ls 8150 branches: 0x39d3015260 1526f _dl_next_ld_env_entry
(/lib64/ld-2.13.so)
ls 8150 branches: 0x39d3015260 1526f _dl_next_ld_env_entry
(/lib64/ld-2.13.so)

tools/perf/builtin-script.c +4 -0

index ac574ea..85376b7 100644
@@ -32,6 +32,7 @@ enum perf_output_field {
  	PERF_OUTPUT_EVNAME          = 1U<<  5,
  	PERF_OUTPUT_TRACE           = 1U<<  6,
  	PERF_OUTPUT_SYM             = 1U<<  7,
+	PERF_OUTPUT_ADDR            = 1U<<  8,
  };
 
  struct output_option {

@@ -46,6 +47,7 @@ struct output_option {
  	{.str = "event", .field = PERF_OUTPUT_EVNAME},
  	{.str = "trace", .field = PERF_OUTPUT_TRACE},
  	{.str = "sym",   .field = PERF_OUTPUT_SYM},
+	{.str = "addr",   .field = PERF_OUTPUT_ADDR},
  };
 
  /* default set to maintain compatibility with current format */

@@ -158,6 +160,8 @@ static void print_sample_start(struct perf_sample
 *sample,
 
  		printf("%s: ", evname ? evname : "(unknown)");
  	}
+	if (PRINT_FIELD(ADDR))
+		printf("0x%" PRIx64, sample->addr);
  }
 

static void process_event(union perf_event *event __unused,

tools/perf/builtin-script.c +1 -1

@@ -829,7 +833,7 @@ static const struct option options[] = {
  	OPT_STRING(0, "symfs",&symbol_conf.symfs, "directory",
  		    "Look for files with symbols relative to this directory"),
  	OPT_CALLBACK('f', "fields", NULL, "str",
-		     "comma separated output fields prepend with 'type:'. Valid
 types: hw,sw,trace. Fields: comm,tid,pid,time,cpu,event,trace,sym",
+		     "comma separated output fields prepend with 'type:'. Valid
 types: hw,sw,trace. Fields: comm,tid,pid,time,cpu,event,trace,sym,addr",
  		     parse_output_fields),

OPT_END()

Quoted 232 lines

Signed-off-by Akihiro Nagai<[email protected]>

Reviewed-by Masami Hiramatsu<[email protected]>

Cc Peter Zijlstra<[email protected]>

Cc Frederic Weisbecker<[email protected]>

Cc Paul Mackerras<[email protected]>

Cc Ingo Molnar<[email protected]>

Cc Arnaldo Carvalho de Melo<[email protected]>

---

  tools/perf/Documentation/perf-branch.txt |   18 ++++-
  tools/perf/builtin-branch.c              |  119 ++++++++++++++++++++++++++++++
  2 files changed, 133 insertions(+), 4 deletions(-)

tools/perf/Documentation/perf-branch.txt +15 -3

index e223267..6c9c253 100644
@@ -3,7 +3,7 @@ perf-branch(1)
 
  NAME
  ----
-perf-branch - Record and print branch-trace-store log
+perf-branch - Record and analyze branch-trace-store log
 
  SYNOPSIS
  --------

@@ -12,7 +12,7 @@ SYNOPSIS
 
  DESCRIPTION
  -----------
-This command records and prints a branch-trace-store log.
+This command records and analyzes a branch-trace-store log.
  Branch-trace-store is a facility of processors. It can record
  addresses of from/to which the execution of a program branches,
  at every branch instruction and interrupt.

@@ -20,13 +20,25 @@ at every branch instruction and interrupt.
  'perf branch record<command>' records branch-trace-store log while
  the specified command is executing. And, save to the file "perf.data".
 
-'perf branch trace' parses recorded branch-trace-store log and prints it.
+'perf branch trace' analyzes recorded branch-trace-store log and prints it.
+The command can select the item to print. For example,
+  'perf branch -a trace'	: prints only address
+  'perf branch -acp trace'	: prints address, command name and pid
 
  OPTIONS
  -------
  -i::
  --input=::
          Specify input file name to analyze.
+-a::
+--addr::
+	Print address. (default)
+-c::
+--comm::
+	Print command name.
+-p::
+--pid::
+	Print pid.
 
  SEE ALSO
  --------

tools/perf/builtin-branch.c +118 -2

index 7dbabf4..22aa25e 100644
@@ -17,6 +17,32 @@
  /* format string to print address */
  #define FMT_ADDR	"%#0" FMT_ADDR_WIDTH "lx"
 
+/* printable items */
+struct exec_info {
+	u64		addr;		/* recorded address by bts */
+	pid_t		pid;		/* tracee process pid */
+	const char	*comm;		/* command name */
+};
+
+#define EI_PID_UNSET	-1
+
+/* flags which item print */
+#define EI_FLAG_PRINT_ADDR		(1<<  0)
+#define EI_FLAG_PRINT_PID		(1<<  1)
+#define EI_FLAG_PRINT_COMM		(1<<  2)
+
+/* it's used when no print item specified */
+#define EI_FLAG_PRINT_DEFAULT		EI_FLAG_PRINT_ADDR
+
+/* print item flags */
+static unsigned long print_flags;
+
+#define is_flags_unset(flags)		(flags == 0)
+
+/* print it when we cannnot analyze and get the information */
+#define EI_UNKNOWN_TEXT			"(unknown)"
+#define EI_UNKNOWN_TEXT_LEN		(sizeof(EI_UNKNOWN_TEXT))
+
  /* default input file name to analyze */
  static const char *input_name = "perf.data";
 

@@ -34,8 +60,25 @@ static const char * const record_args[] = {
  	"-d",
  };
 
+/* set print flags call from parse_options() */
+static int set_print_flags(const struct option *opt, const char *str __unused,
+							int unset __unused)
+{
+	print_flags |= (unsigned long)opt->defval;
+	return 0;
+}
+
  static const struct option branch_options[] = {
  	OPT_STRING('i', "input",&input_name, "file", "input file name"),
+	OPT_CALLBACK_DEFAULT_NOOPT('a', "addr", NULL, NULL,
+				   "print address (default)", set_print_flags,
+				   (void *)EI_FLAG_PRINT_ADDR),
+	OPT_CALLBACK_DEFAULT_NOOPT('p', "pid", NULL, NULL,
+				   "print pid", set_print_flags,
+				   (void *)EI_FLAG_PRINT_PID),
+	OPT_CALLBACK_DEFAULT_NOOPT('c', "comm", NULL, NULL,
+				   "print command name", set_print_flags,
+				   (void *)EI_FLAG_PRINT_COMM),
  	OPT_END()
  };
 

@@ -60,20 +103,89 @@ static bool is_bts_sample(struct perf_sample *sample,
  	return is_bts_event(evsel);
  }
 
+static void init_exec_info(struct exec_info *ei)
+{
+	memset(ei, 0, sizeof(*ei));
+	ei->pid = EI_PID_UNSET;
+}
+
+/* collect printable items to struct exec_info */
+static void fill_exec_info(struct exec_info *ei,
+		struct perf_session *session, union perf_event *event, u64 addr)
+{
+	struct thread *thread;
+
+	ei->addr = addr;
+	ei->pid = event->ip.pid;
+
+	thread = perf_session__findnew(session, event->ip.pid);
+	if (!thread)
+		return;
+	ei->comm = thread->comm;
+}
+
+static void __print_exec_info(struct exec_info *ei)
+{
+	char pid[16];
+	const char *comm;
+
+	if (print_flags&  EI_FLAG_PRINT_PID) {
+		if (ei->pid == EI_PID_UNSET)
+			strncpy(pid, EI_UNKNOWN_TEXT, EI_UNKNOWN_TEXT_LEN);
+		else
+			snprintf(pid, 16, "%d", ei->pid);
+		printf("%5s ", pid);
+	}
+	if (print_flags&  EI_FLAG_PRINT_COMM) {
+		comm = ei->comm ? : EI_UNKNOWN_TEXT;
+		printf("%-12s ", comm);
+	}
+	if (print_flags&  EI_FLAG_PRINT_ADDR)
+		printf(FMT_ADDR " ", ei->addr);
+}
+
+static void print_exec_info(struct exec_info *ei_from, struct exec_info *ei_to)
+{
+	__print_exec_info(ei_from);
+	printf("=>  ");
+	__print_exec_info(ei_to);
+	printf("\n");
+}
+
+static void print_exec_info_header(void)
+{
+	if (print_flags&  EI_FLAG_PRINT_PID)
+		printf("%5s ", "pid");
+	if (print_flags&  EI_FLAG_PRINT_COMM)
+		printf("%-12s ", "command");
+	if (print_flags&  EI_FLAG_PRINT_ADDR)
+		printf("%-" FMT_ADDR_WIDTH "s ", "address");
+	printf("\n");
+}
+
  static int process_sample_event(union perf_event *event __unused,
  		struct perf_sample *sample, struct perf_session *session)
  {
+	struct exec_info ei_from, ei_to;
+
  	if (!is_bts_sample(sample, session))
  		return 0;
 
+	init_exec_info(&ei_from);
+	init_exec_info(&ei_to);
+
  	/* sample->ip is 'from address', sample->addr is 'to address' */
-	printf(FMT_ADDR " =>  " FMT_ADDR "\n", sample->ip, sample->addr);
+	fill_exec_info(&ei_from, session, event, sample->ip);
+	fill_exec_info(&ei_to, session, event, sample->addr);
+
+	print_exec_info(&ei_from,&ei_to);
 
  	return 0;
  }
 
  static struct perf_event_ops event_ops = {
  	.sample			= process_sample_event,
+	.comm			= perf_event__process_comm,
  	.ordered_samples	= false,
  };
 

@@ -87,7 +199,12 @@ static int __cmd_trace(void)
  		return EXIT_FAILURE;
  	}
 
+	/* if print flags are unset, we use default flags */
+	if (is_flags_unset(print_flags))
+		print_flags = EI_FLAG_PRINT_DEFAULT;
+
  	setup_pager();
+	print_exec_info_header();
  	perf_session__process_events(session,&event_ops);
  	perf_session__delete(session);
 
 
--

Quoted 4 lines

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

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

Quoted 25 lines · Akihiro Nagai

Quoted 8 lines

Provide the function to print pid and command name to 'perf branch trace'. Users can select items to print with options. For example,
'perf branch -p trace' prints only pid,
'perf branch -ac trace' prints address and comamnd name. 'perf branch trace' prints only address (default)

This is output sample (perf branch -ac trace):

Quoted 9 lines

command      address
ls           0xffffffff8146fe0e =>  ls           0x0000003806200b20
ls           0xffffffff8146fe0e =>  ls           0x0000003806200b20
ls           0x0000003806200b23 =>  ls           0x0000003806204910
ls           0xffffffff8146fe0e =>  ls           0x0000003806204910
ls           0xffffffff8146fe0e =>  ls           0x0000003806204936
ls           0xffffffff8146fe0e =>  ls           0x000000380620493d
ls           0x0000003806204981 =>  ls           0x00000038062049a3
ls           0x00000038062049a7 =>  ls           0x0000003806204988

This can be easily added to perf-script. e.g,

perf record -e branches:u -c 1 -d -- ls /tmp

perf script -i /tmp/perf.data -f hw:comm,pid,event,sym,addr

Quoted 12 lines

...
ls 8150 branches: 0x39d30144d0 ffffffff8146a48e () ls 8150 branches: 0x39d3014507 ffffffff8146a48e ()
ls 8150 branches: 0x39d3014510 14518 _dl_sysdep_start
(/lib64/ld-2.13.so)
...
ls 8150 branches: 0x39d3015250 1833 process_envvars
(/lib64/ld-2.13.so)
ls 8150 branches: 0x39d3015260 1526f _dl_next_ld_env_entry
(/lib64/ld-2.13.so)
ls 8150 branches: 0x39d3015260 1526f _dl_next_ld_env_entry
(/lib64/ld-2.13.so)

It seems to analyze only 'branch from' address and, print 'branch to' address just in hex.
I would like to analyze both of addresses branch from/to.

Can perf-script do it by writing scripts?

Quoted 37 lines · Akihiro Nagai

Quoted 37 lines · Akihiro Nagai

Quoted 8 lines

Provide the function to print pid and command name to 'perf branch trace'. Users can select items to print with options. For example,
'perf branch -p trace' prints only pid,
'perf branch -ac trace' prints address and comamnd name. 'perf branch trace' prints only address (default)

This is output sample (perf branch -ac trace):

Quoted 9 lines

command      address
ls           0xffffffff8146fe0e =>   ls           0x0000003806200b20
ls           0xffffffff8146fe0e =>   ls           0x0000003806200b20
ls           0x0000003806200b23 =>   ls           0x0000003806204910
ls           0xffffffff8146fe0e =>   ls           0x0000003806204910
ls           0xffffffff8146fe0e =>   ls           0x0000003806204936
ls           0xffffffff8146fe0e =>   ls           0x000000380620493d
ls           0x0000003806204981 =>   ls           0x00000038062049a3
ls           0x00000038062049a7 =>   ls           0x0000003806204988

This can be easily added to perf-script. e.g,

perf record -e branches:u -c 1 -d -- ls /tmp

perf script -i /tmp/perf.data -f hw:comm,pid,event,sym,addr

...
ls 8150 branches: 0x39d30144d0 ffffffff8146a48e () ls 8150 branches: 0x39d3014507 ffffffff8146a48e ()
ls 8150 branches: 0x39d3014510 14518 _dl_sysdep_start
(/lib64/ld-2.13.so)
...
ls 8150 branches: 0x39d3015250 1833 process_envvars
(/lib64/ld-2.13.so)
ls 8150 branches: 0x39d3015260 1526f _dl_next_ld_env_entry
(/lib64/ld-2.13.so)
ls 8150 branches: 0x39d3015260 1526f _dl_next_ld_env_entry
(/lib64/ld-2.13.so)

Quoted 3 lines

It seems to analyze only 'branch from' address and, print 'branch to' address just in hex.
I would like to analyze both of addresses branch from/to.

from is sample->ip? to is sample->addr? In the above example 0x39d3015260 is the value from sample->addr, 1526f is sample->ip which resolves to _dl_next_ld_env_entry from /lib64/ld-2.13.so.

Quoted 3 lines

Can perf-script do it by writing scripts?

If you are pulling the data from a perf sample then you can accomplish the same goal within perf-script.

David

Quoted 3 lines

from is sample->ip? to is sample->addr? In the above example 0x39d3015260 is the value from sample->addr, 1526f is sample->ip which resolves to _dl_next_ld_env_entry from /lib64/ld-2.13.so.

Yes.
In this example, resolved address is only sample->ip (branch from). We need the resolved address of sample->addr (branch to) too, because both of them are addresses of execution code.

Quoted 4 lines

Quoted 3 lines

Can perf-script do it by writing scripts?

Quoted 2 lines

If you are pulling the data from a perf sample then you can accomplish the same goal within perf-script.

It seems that perf-script doesn't have the interface of converting sample->addr to symbol, pid, comm and others. Of course, we can add the interface to perf-script, and it could be another way to implement this function using perf-script.
However, since BTS output usually becomes huge, it would be very slow to convert all the data by python/perl.

Quoted 7 lines · Akihiro Nagai

Quoted 3 lines

from is sample->ip? to is sample->addr? In the above example 0x39d3015260 is the value from sample->addr, 1526f is sample->ip which resolves to _dl_next_ld_env_entry from /lib64/ld-2.13.so.

Yes.
In this example, resolved address is only sample->ip (branch from). We need the resolved address of sample->addr (branch to) too, because both of them are addresses of execution code.

Ok, now I understand. In that case add conversion of sample->addr to symbols to perf-script.

Quoted 11 lines · David Ahern

Quoted 7 lines · Akihiro Nagai

Quoted 3 lines

from is sample->ip? to is sample->addr? In the above example 0x39d3015260 is the value from sample->addr, 1526f is sample->ip which resolves to _dl_next_ld_env_entry from /lib64/ld-2.13.so.

Yes.
In this example, resolved address is only sample->ip (branch from). We need the resolved address of sample->addr (branch to) too, because both of them are addresses of execution code.

Ok, now I understand. In that case add conversion of sample->addr to symbols to perf-script.

I agree that we should rather use perf script for branch dumps. Sorry Akihiro, I think we suggested you to create this dedicated perf branch by the past. But then perf script became the vanilla dump tool in the middle and it seems more suitable today.

We can still create a perf branch later in order to produce some more advanced post-processing tools. But for sample dumps perf script (which starts to show itself as a misnomer BTW) seems to be the right place.

Quoted 18 lines · David Ahern

Quoted 11 lines · Akihiro Nagai

Quoted 7 lines

Quoted 3 lines

from is sample->ip? to is sample->addr? In the above example 0x39d3015260 is the value from sample->addr, 1526f is sample->ip which resolves to _dl_next_ld_env_entry from /lib64/ld-2.13.so.

Yes.
In this example, resolved address is only sample->ip (branch from). We need the resolved address of sample->addr (branch to) too, because both of them are addresses of execution code.

Ok, now I understand. In that case add conversion of sample->addr to symbols to perf-script.

I agree that we should rather use perf script for branch dumps. Sorry Akihiro, I think we suggested you to create this dedicated perf branch by the past. But then perf script became the vanilla dump tool in the middle and it seems more suitable today.

Quoted 3 lines

We can still create a perf branch later in order to produce some more advanced post-processing tools. But for sample dumps perf script (which starts to show itself as a misnomer BTW) seems to be the right place.

Why do something with snakes if its perfectly possible to do in C ?

Quoted 11 lines · David Ahern

Quoted 7 lines · Akihiro Nagai

Quoted 3 lines

from is sample->ip? to is sample->addr? In the above example 0x39d3015260 is the value from sample->addr, 1526f is sample->ip which resolves to _dl_next_ld_env_entry from /lib64/ld-2.13.so.

Yes.
In this example, resolved address is only sample->ip (branch from). We need the resolved address of sample->addr (branch to) too, because both of them are addresses of execution code.

Ok, now I understand. In that case add conversion of sample->addr to symbols to perf-script.

I agree that we should rather use perf script for branch dumps. Sorry Akihiro, I think we suggested you to create this dedicated perf branch by the past. But then perf script became the vanilla dump tool in the middle and it seems more suitable today.

We can still create a perf branch later in order to produce some more advanced post-processing tools. But for sample dumps perf script (which starts to show itself as a misnomer BTW) seems to be the right place.

So, in this context, if we have PERF_SAMPLE_ADDR, we are going to always follow the ip with a "=>" and then resolve the address, etc...

Yeah it makes sense for this default mode. But what about when we'll want a function graph kind of output? This will require a totally different layout. Also PERF_SAMPLE_ADDR may be used for different context in the future.

Perhaps we want a kind of per evsel callback that makes its own interpretation of the pid/tid/dso/sym/etc... options asked by the user?

But well, we can start simple and make and just do the => trick if we have PERF_SAMPLE_ADDR and resolve addr if the user asked the sym. Then when we have the graph output, have these per evsel display callbacks.

There is another email thread about page faults. The user wants sample address resolved to symbols. I was going to look into it next week when I get back from vacation.

Quoted 18 lines · Frederic Weisbecker

Quoted 11 lines · David Ahern

Quoted 7 lines · Akihiro Nagai

Quoted 3 lines

from is sample->ip? to is sample->addr? In the above example 0x39d3015260 is the value from sample->addr, 1526f is sample->ip which resolves to _dl_next_ld_env_entry from /lib64/ld-2.13.so.

Yes.
In this example, resolved address is only sample->ip (branch from). We need the resolved address of sample->addr (branch to) too, because both of them are addresses of execution code.

Ok, now I understand. In that case add conversion of sample->addr to symbols to perf-script.

I agree that we should rather use perf script for branch dumps. Sorry Akihiro, I think we suggested you to create this dedicated perf branch by the past. But then perf script became the vanilla dump tool in the middle and it seems more suitable today.

Quoted 3 lines

We can still create a perf branch later in order to produce some more advanced post-processing tools. But for sample dumps perf script (which starts to show itself as a misnomer BTW) seems to be the right place.

perf-dump?

Quoted 9 lines

So, in this context, if we have PERF_SAMPLE_ADDR, we are going to always follow the ip with a "=>" and then resolve the address, etc...

Yeah it makes sense for this default mode. But what about when we'll want a function graph kind of output? This will require a totally different layout. Also PERF_SAMPLE_ADDR may be used for different context in the future.

Quoted 3 lines

Perhaps we want a kind of per evsel callback that makes its own interpretation of the pid/tid/dso/sym/etc... options asked by the user?

The print addr function can take the evsel as an input. It includes the event type which can be used to decide what the address means.

Quoted 6 lines

But well, we can start simple and make and just do the => trick if we have PERF_SAMPLE_ADDR and resolve addr if the user asked the sym. Then when we have the graph output, have these per evsel display callbacks.

There is another email thread about page faults. The user wants sample address resolved to symbols. I was going to look into it next week when I get back from vacation.

Quoted 5 lines · Frederic Weisbecker

Quoted 4 lines

But well, we can start simple and make and just do the => trick if we have PERF_SAMPLE_ADDR and resolve addr if the user asked the sym. Then when we have the graph output, have these per evsel display callbacks.

Quoted 3 lines

There is another email thread about page faults. The user wants sample address resolved to symbols. I was going to look into it next week when I get back from vacation.

What we seem to need for that is to bring a pagefault tracepoint. We had propositions for that in the past, but work on this is in pause mode it seems.

Quoted 3 lines

What we seem to need for that is to bring a pagefault tracepoint. We had propositions for that in the past, but work on this is in pause mode it seems.

Quoted 3 lines · Arnaldo Carvalho de Melo

Quoted 3 lines

What we seem to need for that is to bring a pagefault tracepoint. We had propositions for that in the past, but work on this is in pause mode it seems.

Huh, whot? You can get that using PERF_COUNT_SW_PAGE_FAULT and PERF_SAMPLE_ADDR.

Quoted 7 lines · Peter Zijlstra

Quoted 3 lines · Arnaldo Carvalho de Melo

Quoted 3 lines

What we seem to need for that is to bring a pagefault tracepoint. We had propositions for that in the past, but work on this is in pause mode it seems.

Huh, whot? You can get that using PERF_COUNT_SW_PAGE_FAULT and PERF_SAMPLE_ADDR.

Where are we doing that? I can't find the code that handles it.

Quoted 6 lines · Frederic Weisbecker

Quoted 5 lines · Peter Zijlstra

Quoted 3 lines · Arnaldo Carvalho de Melo

Quoted 3 lines

What we seem to need for that is to bring a pagefault tracepoint. We had propositions for that in the past, but work on this is in pause mode it seems.

Quoted 4 lines

Quoted 2 lines

Huh, whot? You can get that using PERF_COUNT_SW_PAGE_FAULT and PERF_SAMPLE_ADDR.

Where are we doing that? I can't find the code that handles it.

That's what the other email thread was about, and the solution is just that - perf record -e faults -c 1 -d ... Then it comes to dumping the information. That's easy with the current perf-script.

Quoted 3 lines · Arnaldo Carvalho de Melo

Quoted 3 lines

What we seem to need for that is to bring a pagefault tracepoint. We had propositions for that in the past, but work on this is in pause mode it seems.

Huh, whot? You can get that using PERF_COUNT_SW_PAGE_FAULT and PERF_SAMPLE_ADDR.

Em Wed, Apr 06, 2011 at 02:15:07PM +0200, Frederic Weisbecker escreveu:

Quoted 7 lines · David Ahern

Quoted 5 lines · Frederic Weisbecker

Quoted 4 lines

But well, we can start simple and make and just do the => trick if we have PERF_SAMPLE_ADDR and resolve addr if the user asked the sym. Then when we have the graph output, have these per evsel display callbacks.

Quoted 7 lines

Quoted 3 lines

There is another email thread about page faults. The user wants sample address resolved to symbols. I was going to look into it next week when I get back from vacation.

What we seem to need for that is to bring a pagefault tracepoint. We had propositions for that in the past, but work on this is in pause mode it seems.

Isn't there one in the 'tip/tmp.perf/trace' tmp branch? Lemme see...

Yeah, and it is even yours ;-)

commit 6a824e89c0dfe6bce3d7e85f987ec9c8e7304b34

Author: Frederic Weisbecker <[email protected]>
Date:   Fri Nov 12 05:35:06 2010 +0100

perf, mm: Add fault tracing

Part of that are two modified patches from Jiri Olsa who added the fault tracepoints. I had to split them in two tracepoints so that we get the faults handling duration.

Originally-from: Frederic Weisbecker <[email protected]>

Signed-off-by Ingo Molnar <[email protected]>

Signed-off-by Thomas Gleixner <[email protected]>

Can we dust this one off and get the ball rolling again?

Quoted 10 lines

Isn't there one in the 'tip/tmp.perf/trace' tmp branch? Lemme see...

Yeah, and it is even yours ;-)

commit 6a824e89c0dfe6bce3d7e85f987ec9c8e7304b34

Author: Frederic Weisbecker <[email protected]>
Date:   Fri Nov 12 05:35:06 2010 +0100

perf, mm: Add fault tracing

Quoted 7 lines

Part of that are two modified patches from Jiri Olsa who added the fault tracepoints. I had to split them in two tracepoints so that we get the faults handling duration.

Originally-from: Frederic Weisbecker <[email protected]>

Signed-off-by Ingo Molnar <[email protected]>

Signed-off-by Thomas Gleixner <[email protected]>

That forgets to mention it's based on Jiri Olsa's patch :)

"tracing,mm - add kernel pagefault tracepoint for x86 & x86_64"

(Message id <[email protected]>).

Quoted 2 lines

Can we dust this one off and get the ball rolling again?

I prefer someone comes with a real need before me or Jiri respin that. There was perf trace but its development seems to be stale now.

The page fault software event seem to be enough for basic dump requests. I don't like software events and prefer tracepoints in general but as long as the current implementation is enough and people don't need to measure page fault servicing time, write scripts or so, we are probably fine.

Quoted 11 lines · David Ahern

Quoted 7 lines · Akihiro Nagai

Quoted 3 lines

from is sample->ip? to is sample->addr? In the above example 0x39d3015260 is the value from sample->addr, 1526f is sample->ip which resolves to _dl_next_ld_env_entry from /lib64/ld-2.13.so.

Yes.
In this example, resolved address is only sample->ip (branch from). We need the resolved address of sample->addr (branch to) too, because both of them are addresses of execution code.

Ok, now I understand. In that case add conversion of sample->addr to symbols to perf-script.

I agree that we should rather use perf script for branch dumps. Sorry Akihiro, I think we suggested you to create this dedicated perf branch by the past. But then perf script became the vanilla dump tool in the middle and it seems more suitable today.

We can still create a perf branch later in order to produce some more advanced post-processing tools. But for sample dumps perf script (which starts to show itself as a misnomer BTW) seems to be the right place.

Quoted 18 lines · Frederic Weisbecker

Quoted 11 lines · David Ahern

Quoted 7 lines · Akihiro Nagai

Quoted 3 lines

from is sample->ip? to is sample->addr? In the above example 0x39d3015260 is the value from sample->addr, 1526f is sample->ip which resolves to _dl_next_ld_env_entry from /lib64/ld-2.13.so.

Yes.
In this example, resolved address is only sample->ip (branch from). We need the resolved address of sample->addr (branch to) too, because both of them are addresses of execution code.

Ok, now I understand. In that case add conversion of sample->addr to symbols to perf-script.

I agree that we should rather use perf script for branch dumps. Sorry Akihiro, I think we suggested you to create this dedicated perf branch by the past. But then perf script became the vanilla dump tool in the middle and it seems more suitable today.

Quoted 3 lines

We can still create a perf branch later in order to produce some more advanced post-processing tools. But for sample dumps perf script (which starts to show itself as a misnomer BTW) seems to be the right place.

Finally, I would like to create coverage test tools using BTS on perf. I'm working on the project "Btrax" that is a coverage test tool using BTS. The URL is: http://sourceforge.net/projects/btrax/

And, I would like to implement other functions on perf-branch too. For example, call graph, source code browser like perf-annotate which can show executed codes.
So, I wolud like to continue to develop perf-branch.

Quoted 19 lines · Akihiro Nagai

Quoted 18 lines · Frederic Weisbecker

Quoted 11 lines · David Ahern

Quoted 7 lines · Akihiro Nagai

Quoted 3 lines

from is sample->ip? to is sample->addr? In the above example 0x39d3015260 is the value from sample->addr, 1526f is sample->ip which resolves to _dl_next_ld_env_entry from /lib64/ld-2.13.so.

Yes.
In this example, resolved address is only sample->ip (branch from). We need the resolved address of sample->addr (branch to) too, because both of them are addresses of execution code.

Ok, now I understand. In that case add conversion of sample->addr to symbols to perf-script.

I agree that we should rather use perf script for branch dumps. Sorry Akihiro, I think we suggested you to create this dedicated perf branch by the past. But then perf script became the vanilla dump tool in the middle and it seems more suitable today.

Quoted 6 lines

Quoted 3 lines

We can still create a perf branch later in order to produce some more advanced post-processing tools. But for sample dumps perf script (which starts to show itself as a misnomer BTW) seems to be the right place.

Finally, I would like to create coverage test tools using BTS on perf. I'm working on the project "Btrax" that is a coverage test tool using BTS. The URL is: http://sourceforge.net/projects/btrax/

Cool, what is this tool doing? How is it different from perf branch?

Quoted 6 lines

And, I would like to implement other functions on perf-branch too. For example, call graph, source code browser like perf-annotate which can show executed codes.
So, I wolud like to continue to develop perf-branch.

And you're very welcome to do so. Such features have a nice potential I think.

Thanks.

Hi,

This patch series provides the commands 'perf branch record' and 'perf branch trace' version 3. These commands record and analyze a BTS (Branch Trace Store) log. And, they provide the interface to use BTS log for application developers.

BTS is a facility of Intel x86 processors, which records the address of 'branch to/from' on every branch/jump instruction and interrupt. This facility is very useful for developers to test their software, for example, coverage test, execution path analysis, dynamic step count ...etc. These test tools have a big advantage, which user doesn't have to modify target executable binaries, because the BTS is a hardware feauture.

But, there are few applications using BTS. Reasons I guess are ...
- Few people know what BTS is.
- Few people know how to use BTS on Linux box.
- It's hard to analyze the BTS log because it includes just a series of addresses.

So, I want to provide a user-friendly interface to BTS for application developers.

About new sub commands
========================
'perf branch record' provides an easy way to record BTS log. Usage is 'perf branch record <command>'. This command is just an alias to 'perf record -e branches:u -c 1 <command>'. But, new one is more simple and more intuitive.

'perf branch trace' can parse and analyze recorded BTS log and print various information of execution path. This command can show address, pid, command name, function+offset, file path of elf.
You can choose the printed information with option.

Example: 'perf branch trace'
function+offset

irq_return+0x0  => _start+0x0
irq_return+0x0  => _start+0x0
_start+0x3      => _dl_start+0x0
irq_return+0x0  => _dl_start+0x0
irq_return+0x0  => _dl_start+0x26
irq_return+0x0  => _dl_start+0x2d

Quoted 5 lines

'perf branch trace' can parse and analyze recorded BTS log and print various information of execution path. This command can show address, pid, command name, function+offset, file path of elf.
You can choose the printed information with option.

Quoted 8 lines

Example: 'perf branch trace'
function+offset

irq_return+0x0  =>  _start+0x0
irq_return+0x0  =>  _start+0x0
_start+0x3      =>  _dl_start+0x0
irq_return+0x0  =>  _dl_start+0x0
irq_return+0x0  =>  _dl_start+0x26
irq_return+0x0  =>  _dl_start+0x2d

These results are a bit surprising. May be we can jump once from irq_return to _start, in the first schedule() of a new task perhaps, but thereafter I would expect further jumps not to happen from irq_return, but rather from _start. When we have x as a destination in line n, then I would expect to have x as a source in n + 1.

Also we are supposed to only trace BTS in userspace, but perhaps, if we are interrupted, after the execution of the iret instruction, BTS considers the following jump "iret -> interrupted inst" as a branch in userspace. After all it makes sense, it is a jump in userspace.

So BTS, because of the way it defines a jump inside userspace, traces irq returns but not irq entries, that would explain the trace you gave as an example.

I suspect we want to filter irq returns. ie: if the source comes from the kernel, then filter it by default. And then we can later think about an option to enable interrupt return tracing if people want them.

Thanks.

(2011/03/30 23:46), Frederic Weisbecker wrote:
<snip>

Quoted 14 lines

Quoted 5 lines

'perf branch trace' can parse and analyze recorded BTS log and print various information of execution path. This command can show address, pid, command name, function+offset, file path of elf.
You can choose the printed information with option.

Quoted 8 lines

Example: 'perf branch trace'
function+offset

irq_return+0x0  =>  _start+0x0
irq_return+0x0  =>  _start+0x0
_start+0x3      =>  _dl_start+0x0
irq_return+0x0  =>  _dl_start+0x0
irq_return+0x0  =>  _dl_start+0x26
irq_return+0x0  =>  _dl_start+0x2d

Quoted 6 lines

These results are a bit surprising. May be we can jump once from irq_return to _start, in the first schedule() of a new task perhaps, but thereafter I would expect further jumps not to happen from irq_return, but rather from _start. When we have x as a destination in line n, then I would expect to have x as a source in n + 1.

Agree with the opinion "irq_start" surprising users. However, I think it is not a better solution that uses a previous destination as a next source.
Because, users want to know what happen in userspace and, do not want to know interrupts from kernel.

I think the better solution is to implement the filter that eliminate the record including kernel functions from output.

For example, leading example will be filtered like this.

_start+0x3 => _dl_start+0x0

In the future, I think the solution is available that using BTS records with trace event like irq:irq_handler_entry to analyze interrupt. However, to do it, we need to fix perf.

Quoted 10 lines

Also we are supposed to only trace BTS in userspace, but perhaps, if we are interrupted, after the execution of the iret instruction, BTS considers the following jump "iret -> interrupted inst" as a branch in userspace. After all it makes sense, it is a jump in userspace.

So BTS, because of the way it defines a jump inside userspace, traces irq returns but not irq entries, that would explain the trace you gave as an example.

Quoted 4 lines

I suspect we want to filter irq returns. ie: if the source comes from the kernel, then filter it by default. And then we can later think about an option to enable interrupt return tracing if people want them.

Agree.
I will implement the option that enable/disable the filter.

Hi,

This patch series provides the commands 'perf branch record' and 'perf branch trace' version 3. These commands record and analyze a BTS (Branch Trace Store) log. And, they provide the interface to use BTS log for application developers.

BTS is a facility of Intel x86 processors, which records the address of 'branch to/from' on every branch/jump instruction and interrupt. This facility is very useful for developers to test their software, for example, coverage test, execution path analysis, dynamic step count ...etc. These test tools have a big advantage, which user doesn't have to modify target executable binaries, because the BTS is a hardware feauture.

But, there are few applications using BTS. Reasons I guess are ...
- Few people know what BTS is.
- Few people know how to use BTS on Linux box.
- It's hard to analyze the BTS log because it includes just a series of addresses.

So, I want to provide a user-friendly interface to BTS for application developers.

About new sub commands
========================
'perf branch record' provides an easy way to record BTS log. Usage is 'perf branch record <command>'. This command is just an alias to 'perf record -e branches:u -c 1 <command>'. But, new one is more simple and more intuitive.

'perf branch trace' can parse and analyze recorded BTS log and print various information of execution path. This command can show address, pid, command name, function+offset, file path of elf.
You can choose the printed information with option.

Example: 'perf branch trace'
function+offset

irq_return+0x0  => _start+0x0
irq_return+0x0  => _start+0x0
_start+0x3      => _dl_start+0x0
irq_return+0x0  => _dl_start+0x0
irq_return+0x0  => _dl_start+0x26
irq_return+0x0  => _dl_start+0x2d
_dl_start+0x71  => _dl_start+0x93
_dl_start+0x97  => _dl_start+0x78

...

This is the default behavior of 'perf branch trace'. It prints function+offset.

Example2: 'perf branch -cas trace'
command address function+offset
ls 0xffffffff8146fe0e irq_return+0x0 => ls 0x0000003806200b20 _start+0x0

Quoted 48 lines · Akihiro Nagai

Hi,

This patch series provides the commands 'perf branch record' and 'perf branch trace' version 3. These commands record and analyze a BTS (Branch Trace Store) log. And, they provide the interface to use BTS log for application developers.

BTS is a facility of Intel x86 processors, which records the address of 'branch to/from' on every branch/jump instruction and interrupt. This facility is very useful for developers to test their software, for example, coverage test, execution path analysis, dynamic step count ...etc. These test tools have a big advantage, which user doesn't have to modify target executable binaries, because the BTS is a hardware feauture.

But, there are few applications using BTS. Reasons I guess are ...
- Few people know what BTS is.
- Few people know how to use BTS on Linux box.
- It's hard to analyze the BTS log because it includes just a series of addresses.

So, I want to provide a user-friendly interface to BTS for application developers.

About new sub commands
========================
'perf branch record' provides an easy way to record BTS log. Usage is 'perf branch record<command>'. This command is just an alias to 'perf record -e branches:u -c 1<command>'. But, new one is more simple and more intuitive.

'perf branch trace' can parse and analyze recorded BTS log and print various information of execution path. This command can show address, pid, command name, function+offset, file path of elf.
You can choose the printed information with option.

Example: 'perf branch trace'
function+offset

irq_return+0x0  =>  _start+0x0
irq_return+0x0  =>  _start+0x0
_start+0x3      =>  _dl_start+0x0
irq_return+0x0  =>  _dl_start+0x0
irq_return+0x0  =>  _dl_start+0x26
irq_return+0x0  =>  _dl_start+0x2d
_dl_start+0x71  =>  _dl_start+0x93
_dl_start+0x97  =>  _dl_start+0x78

...

This is the default behavior of 'perf branch trace'. It prints function+offset.

Quoted 3 lines

Example2: 'perf branch -cas trace'
command address function+offset
ls 0xffffffff8146fe0e irq_return+0x0 => ls 0x0000003806200b20 _start+0x0

You probably want to display the comm (and/or the pid/tid) only once. Those are not going to change between the source and destination.