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


Groups > linux.kernel > #1381287 > unrolled thread

[PATCH v4 0/6] perf tools: Use SIGUSR2 control data dumpping

Started byWang Nan <wangnan0@huawei.com>
First post2016-04-18 08:40 +0200
Last post2016-04-18 08:40 +0200
Articles 10 — 3 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH v4 0/6] perf tools: Use SIGUSR2 control data dumpping Wang Nan <wangnan0@huawei.com> - 2016-04-18 08:40 +0200
    [PATCH v4 3/6] perf record: Force enable --timestamp-filename when --switch-output is provided Wang Nan <wangnan0@huawei.com> - 2016-04-18 08:40 +0200
    [PATCH v4 1/6] perf tools: Derive trigger class from auxtrace_snapshot Wang Nan <wangnan0@huawei.com> - 2016-04-18 08:40 +0200
      Re: [PATCH v4 1/6] perf tools: Derive trigger class from  auxtrace_snapshot Jiri Olsa <jolsa@redhat.com> - 2016-04-18 15:50 +0200
        Re: [PATCH v4 1/6] perf tools: Derive trigger class from  auxtrace_snapshot "Wangnan (F)" <wangnan0@huawei.com> - 2016-04-18 16:30 +0200
          Re: [PATCH v4 1/6] perf tools: Derive trigger class from  auxtrace_snapshot Jiri Olsa <jolsa@redhat.com> - 2016-04-18 16:30 +0200
            Re: [PATCH v4 1/6] perf tools: Derive trigger class from  auxtrace_snapshot "Wangnan (F)" <wangnan0@huawei.com> - 2016-04-18 16:40 +0200
    [PATCH v4 6/6] perf record: Generate tracking events for process forked by perf Wang Nan <wangnan0@huawei.com> - 2016-04-18 08:40 +0200
    [PATCH v4 5/6] perf record: Re-synthesize tracking events after output switching Wang Nan <wangnan0@huawei.com> - 2016-04-18 08:40 +0200
    [PATCH v4 4/6] perf record: Disable buildid cache options by default in switch output mode Wang Nan <wangnan0@huawei.com> - 2016-04-18 08:40 +0200

#1381287 — [PATCH v4 0/6] perf tools: Use SIGUSR2 control data dumpping

FromWang Nan <wangnan0@huawei.com>
Date2016-04-18 08:40 +0200
Subject[PATCH v4 0/6] perf tools: Use SIGUSR2 control data dumpping
Message-ID<rpb0K-WR-9@gated-at.bofh.it>
v3 -> v4: Reimplement trigger class, rename states, describe the transitions
          of it in header and change log.

Signed-off-by: Wang Nan <wangnan0@huawei.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: He Kuang <hekuang@huawei.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Zefan Li <lizefan@huawei.com>
Cc: pi3orama@163.com

Wang Nan (6):
  perf tools: Derive trigger class from auxtrace_snapshot
  perf record: Split output into multiple files via '--switch-output'
  perf record: Force enable --timestamp-filename when --switch-output is
    provided
  perf record: Disable buildid cache options by default in switch output
    mode
  perf record: Re-synthesize tracking events after output switching
  perf record: Generate tracking events for process forked by perf

 tools/perf/Documentation/perf-record.txt |  13 +++
 tools/perf/builtin-record.c              | 176 +++++++++++++++++++++----------
 tools/perf/util/trigger.h                | 123 +++++++++++++++++++++
 3 files changed, 255 insertions(+), 57 deletions(-)
 create mode 100644 tools/perf/util/trigger.h

-- 
1.8.3.4

[toc] | [next] | [standalone]


#1381288 — [PATCH v4 3/6] perf record: Force enable --timestamp-filename when --switch-output is provided

FromWang Nan <wangnan0@huawei.com>
Date2016-04-18 08:40 +0200
Subject[PATCH v4 3/6] perf record: Force enable --timestamp-filename when --switch-output is provided
Message-ID<rpb0K-WR-11@gated-at.bofh.it>
In reply to#1381287
Without this patch, the last output doesn't have timestamp appended if
--timestamp-filename is not explicitly provided. For example:

  # perf record -a --switch-output &
  [1] 11224
  # kill -s SIGUSR2 11224
  [ perf record: dump data: Woken up 1 times ]
  # [ perf record: Dump perf.data.2015122622372823 ]

  # fg
  perf record -a --switch-output
  ^C[ perf record: Woken up 1 times to write data ]
  [ perf record: Captured and wrote 0.027 MB perf.data (540 samples) ]

  # ls -l
  total 836
  -rw------- 1 root root  33256 Dec 26 22:37 perf.data   <---- *Odd*
  -rw------- 1 root root 817156 Dec 26 22:37 perf.data.2015122622372823

Signed-off-by: Wang Nan <wangnan0@huawei.com>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Zefan Li <lizefan@huawei.com>
Cc: pi3orama@163.com
Link: http://lkml.kernel.org/r/1460643725-167413-4-git-send-email-wangnan0@huawei.com
Signed-off-by: He Kuang <hekuang@huawei.com>
[ Updated man page, that also got an entry for --timestamp-filename ]
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
 tools/perf/Documentation/perf-record.txt | 5 +++++
 tools/perf/builtin-record.c              | 3 +++
 2 files changed, 8 insertions(+)

diff --git a/tools/perf/Documentation/perf-record.txt b/tools/perf/Documentation/perf-record.txt
index a77a431..79a8a14 100644
--- a/tools/perf/Documentation/perf-record.txt
+++ b/tools/perf/Documentation/perf-record.txt
@@ -347,6 +347,9 @@ Configure all used events to run in kernel space.
 --all-user::
 Configure all used events to run in user space.
 
+--timestamp-filename
+Append timestamp to output file name.
+
 --switch-output::
 Generate multiple perf.data files, timestamp prefixed, switching to a new one
 when receiving a SIGUSR2.
@@ -355,6 +358,8 @@ A possible use case is to, given an external event, slice the perf.data file
 that gets then processed, possibly via a perf script, to decide if that
 particular perf.data snapshot should be kept or not.
 
+Implies --timestamp-filename.
+
 SEE ALSO
 --------
 linkperf:perf-stat[1], linkperf:perf-list[1]
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 7fd0b2d..c389d52 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -1346,6 +1346,9 @@ int cmd_record(int argc, const char **argv, const char *prefix __maybe_unused)
 		return -EINVAL;
 	}
 
+	if (rec->switch_output)
+		rec->timestamp_filename = true;
+
 	if (!rec->itr) {
 		rec->itr = auxtrace_record__init(rec->evlist, &err);
 		if (err)
-- 
1.8.3.4

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


#1381290 — [PATCH v4 1/6] perf tools: Derive trigger class from auxtrace_snapshot

FromWang Nan <wangnan0@huawei.com>
Date2016-04-18 08:40 +0200
Subject[PATCH v4 1/6] perf tools: Derive trigger class from auxtrace_snapshot
Message-ID<rpb0K-WR-15@gated-at.bofh.it>
In reply to#1381287
Use 'trigger' to model operations which need to be executed when
an event (a signal, for example) is observed.

States and transits:

 OFF--(on)--> READY --(toggle)--> TOGGLED --(process)--> PROCESSING
                ^                    |                      |
                |                    |                      |
                |                 (ready)                (ready)
                |                    |                      |
                 \__________________/______________________/

is_toggled and is_ready are two key functions to query the state of
a trigger. is_toggled means the event already happen; is_ready means the
trigger is waiting for the event.

'PROCESSING' represents a state the event happens and be observed, and
the processing is on the way so can't accept a new event immediately.

auxtrace_record__snapshot_started and auxtrace_snapshot_err are removed
and switch to trigger.

Signed-off-by: Wang Nan <wangnan0@huawei.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: He Kuang <hekuang@huawei.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Zefan Li <lizefan@huawei.com>
Cc: pi3orama@163.com
---
 tools/perf/builtin-record.c |  73 +++++++-------------------
 tools/perf/util/trigger.h   | 123 ++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 142 insertions(+), 54 deletions(-)
 create mode 100644 tools/perf/util/trigger.h

diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 5b4758a..0ff2422 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -34,6 +34,7 @@
 #include "util/parse-regs-options.h"
 #include "util/llvm-utils.h"
 #include "util/bpf-loader.h"
+#include "util/trigger.h"
 #include "asm/bug.h"
 
 #include <unistd.h>
@@ -127,44 +128,7 @@ static volatile int done;
 static volatile int signr = -1;
 static volatile int child_finished;
 
-static volatile enum {
-	AUXTRACE_SNAPSHOT_OFF = -1,
-	AUXTRACE_SNAPSHOT_DISABLED = 0,
-	AUXTRACE_SNAPSHOT_ENABLED = 1,
-} auxtrace_snapshot_state = AUXTRACE_SNAPSHOT_OFF;
-
-static inline void
-auxtrace_snapshot_on(void)
-{
-	auxtrace_snapshot_state = AUXTRACE_SNAPSHOT_DISABLED;
-}
-
-static inline void
-auxtrace_snapshot_enable(void)
-{
-	if (auxtrace_snapshot_state == AUXTRACE_SNAPSHOT_OFF)
-		return;
-	auxtrace_snapshot_state = AUXTRACE_SNAPSHOT_ENABLED;
-}
-
-static inline void
-auxtrace_snapshot_disable(void)
-{
-	if (auxtrace_snapshot_state == AUXTRACE_SNAPSHOT_OFF)
-		return;
-	auxtrace_snapshot_state = AUXTRACE_SNAPSHOT_DISABLED;
-}
-
-static inline bool
-auxtrace_snapshot_is_enabled(void)
-{
-	if (auxtrace_snapshot_state == AUXTRACE_SNAPSHOT_OFF)
-		return false;
-	return auxtrace_snapshot_state == AUXTRACE_SNAPSHOT_ENABLED;
-}
-
-static volatile int auxtrace_snapshot_err;
-static volatile int auxtrace_record__snapshot_started;
+static DEFINE_TRIGGER(auxtrace_snapshot);
 
 static void sig_handler(int sig)
 {
@@ -282,11 +246,12 @@ static void record__read_auxtrace_snapshot(struct record *rec)
 {
 	pr_debug("Recording AUX area tracing snapshot\n");
 	if (record__auxtrace_read_snapshot_all(rec) < 0) {
-		auxtrace_snapshot_err = -1;
+		auxtrace_snapshot_error();
 	} else {
-		auxtrace_snapshot_err = auxtrace_record__snapshot_finish(rec->itr);
-		if (!auxtrace_snapshot_err)
-			auxtrace_snapshot_enable();
+		if (auxtrace_record__snapshot_finish(rec->itr))
+			auxtrace_snapshot_error();
+		else
+			auxtrace_snapshot_ready();
 	}
 }
 
@@ -815,21 +780,21 @@ static int __cmd_record(struct record *rec, int argc, const char **argv)
 		perf_evlist__enable(rec->evlist);
 	}
 
-	auxtrace_snapshot_enable();
+	auxtrace_snapshot_ready();
 	for (;;) {
 		unsigned long long hits = rec->samples;
 
 		if (record__mmap_read_all(rec) < 0) {
-			auxtrace_snapshot_disable();
+			auxtrace_snapshot_error();
 			err = -1;
 			goto out_child;
 		}
 
-		if (auxtrace_record__snapshot_started) {
-			auxtrace_record__snapshot_started = 0;
-			if (!auxtrace_snapshot_err)
+		if (auxtrace_snapshot_is_toggled()) {
+			auxtrace_snapshot_process();
+			if (!auxtrace_snapshot_is_error())
 				record__read_auxtrace_snapshot(rec);
-			if (auxtrace_snapshot_err) {
+			if (auxtrace_snapshot_is_error()) {
 				pr_err("AUX area tracing snapshot failed\n");
 				err = -1;
 				goto out_child;
@@ -858,12 +823,12 @@ static int __cmd_record(struct record *rec, int argc, const char **argv)
 		 * disable events in this case.
 		 */
 		if (done && !disabled && !target__none(&opts->target)) {
-			auxtrace_snapshot_disable();
+			auxtrace_snapshot_off();
 			perf_evlist__disable(rec->evlist);
 			disabled = true;
 		}
 	}
-	auxtrace_snapshot_disable();
+	auxtrace_snapshot_off();
 
 	if (forks && workload_exec_errno) {
 		char msg[STRERR_BUFSIZE];
@@ -1447,9 +1412,9 @@ out_symbol_exit:
 
 static void snapshot_sig_handler(int sig __maybe_unused)
 {
-	if (!auxtrace_snapshot_is_enabled())
+	if (!auxtrace_snapshot_is_ready())
 		return;
-	auxtrace_snapshot_disable();
-	auxtrace_snapshot_err = auxtrace_record__snapshot_start(record.itr);
-	auxtrace_record__snapshot_started = 1;
+	auxtrace_snapshot_toggle();
+	if (auxtrace_record__snapshot_start(record.itr))
+		auxtrace_snapshot_error();
 }
diff --git a/tools/perf/util/trigger.h b/tools/perf/util/trigger.h
new file mode 100644
index 0000000..852d876
--- /dev/null
+++ b/tools/perf/util/trigger.h
@@ -0,0 +1,123 @@
+#ifndef __TRIGGER_H_
+#define __TRIGGER_H_ 1
+
+#include "util/debug.h"
+#include "asm/bug.h"
+
+/*
+ * Use trigger to model operations which need to be executed when
+ * an event (a signal, for example) is observed.
+ *
+ * States and transits:
+ *
+ *
+ *  OFF--(on)--> READY --(toggle)--> TOGGLED --(process)--> PROCESSING
+ *                 ^                    |                      |
+ *                 |                    |                      |
+ *                 |                 (ready)                (ready)
+ *                 |                    |                      |
+ *                  \__________________/______________________/
+ *
+ * is_toggled and is_ready are two key functions to query the state of
+ * a trigger. is_toggled means the event already happen; is_ready means the
+ * trigger is waiting for the event.
+ *
+ * 'PROCESSING' represents a state the event happens and be observed, and
+ * the processing is on the way so can't accept a new event immediately.
+ */
+
+struct trigger {
+	volatile enum {
+		TRIGGER_ERROR		= -2,
+		TRIGGER_OFF		= -1,
+		TRIGGER_READY		= 0,
+		TRIGGER_TOGGLED		= 1,
+		TRIGGER_PROCESSING	= 2,
+	} state;
+	const char *name;
+};
+
+#define TRIGGER_WARN_ONCE(t, exp) \
+	WARN_ONCE(t->state != exp, "trigger '%s' state transist error: %d in %s()\n", \
+		  t->name, t->state, __func__)
+
+static inline bool trigger_is_available(struct trigger *t)
+{
+	return t->state >= 0;
+}
+
+static inline bool trigger_is_error(struct trigger *t)
+{
+	return t->state <= TRIGGER_ERROR;
+}
+
+static inline void trigger_on(struct trigger *t)
+{
+	TRIGGER_WARN_ONCE(t, TRIGGER_OFF);
+	t->state = TRIGGER_READY;
+}
+
+static inline void trigger_ready(struct trigger *t)
+{
+	if (!trigger_is_available(t))
+		return;
+	t->state = TRIGGER_READY;
+}
+
+static inline void trigger_toggle(struct trigger *t)
+{
+	if (!trigger_is_available(t))
+		return;
+	TRIGGER_WARN_ONCE(t, TRIGGER_READY);
+	t->state = TRIGGER_TOGGLED;
+}
+
+static inline void trigger_process(struct trigger *t)
+{
+	if (!trigger_is_available(t))
+		return;
+	TRIGGER_WARN_ONCE(t, TRIGGER_TOGGLED);
+	t->state = TRIGGER_PROCESSING;
+}
+
+static inline void trigger_off(struct trigger *t)
+{
+	if (!trigger_is_available(t))
+		return;
+	t->state = TRIGGER_OFF;
+}
+
+static inline void trigger_error(struct trigger *t)
+{
+	t->state = TRIGGER_ERROR;
+}
+
+static inline bool trigger_is_ready(struct trigger *t)
+{
+	return t->state == TRIGGER_READY;
+}
+
+static inline bool trigger_is_toggled(struct trigger *t)
+{
+	return t->state == TRIGGER_TOGGLED;
+}
+
+#define __TRIGGER_VAR(n) n##_state
+#define __DEF_TRIGGER_VOID_FUNC(n, op)	\
+static inline void n##_##op(void) {trigger_##op(&__TRIGGER_VAR(n)); }
+#define __DEF_TRIGGER_BOOL_FUNC(n, op)	\
+static inline bool n##_##op(void) {return trigger_##op(&__TRIGGER_VAR(n)); }
+
+#define DEFINE_TRIGGER(n)					\
+struct trigger n##_state = {.state = TRIGGER_OFF, .name = #n};	\
+__DEF_TRIGGER_VOID_FUNC(n, on)					\
+__DEF_TRIGGER_VOID_FUNC(n, ready)				\
+__DEF_TRIGGER_VOID_FUNC(n, toggle)				\
+__DEF_TRIGGER_VOID_FUNC(n, process)				\
+__DEF_TRIGGER_VOID_FUNC(n, off)					\
+__DEF_TRIGGER_VOID_FUNC(n, error)				\
+__DEF_TRIGGER_BOOL_FUNC(n, is_ready)				\
+__DEF_TRIGGER_BOOL_FUNC(n, is_toggled)				\
+__DEF_TRIGGER_BOOL_FUNC(n, is_error)
+
+#endif
-- 
1.8.3.4

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


#1381717 — Re: [PATCH v4 1/6] perf tools: Derive trigger class from auxtrace_snapshot

FromJiri Olsa <jolsa@redhat.com>
Date2016-04-18 15:50 +0200
SubjectRe: [PATCH v4 1/6] perf tools: Derive trigger class from auxtrace_snapshot
Message-ID<rphIT-6ug-27@gated-at.bofh.it>
In reply to#1381290
On Mon, Apr 18, 2016 at 06:32:08AM +0000, Wang Nan wrote:
> Use 'trigger' to model operations which need to be executed when
> an event (a signal, for example) is observed.
> 
> States and transits:
> 
>  OFF--(on)--> READY --(toggle)--> TOGGLED --(process)--> PROCESSING
>                 ^                    |                      |
>                 |                    |                      |
>                 |                 (ready)                (ready)
>                 |                    |                      |
>                  \__________________/______________________/
> 
> is_toggled and is_ready are two key functions to query the state of
> a trigger. is_toggled means the event already happen; is_ready means the
> trigger is waiting for the event.
> 
> 'PROCESSING' represents a state the event happens and be observed, and
> the processing is on the way so can't accept a new event immediately.

hum, I must be missing something.. but I dont see how you're
using this state except for smal window within:

                if (auxtrace_snapshot_is_toggled()) {
 ->                     auxtrace_snapshot_process();
                        if (!auxtrace_snapshot_is_error())
 ->                              record__read_auxtrace_snapshot(rec);

but no other place queries or depends on this state

also the switch_output code does not seem to use this transition at all

thanks,
jirka

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


#1381749 — Re: [PATCH v4 1/6] perf tools: Derive trigger class from auxtrace_snapshot

From"Wangnan (F)" <wangnan0@huawei.com>
Date2016-04-18 16:30 +0200
SubjectRe: [PATCH v4 1/6] perf tools: Derive trigger class from auxtrace_snapshot
Message-ID<rpilz-75e-9@gated-at.bofh.it>
In reply to#1381717

On 2016/4/18 21:45, Jiri Olsa wrote:
> On Mon, Apr 18, 2016 at 06:32:08AM +0000, Wang Nan wrote:
>> Use 'trigger' to model operations which need to be executed when
>> an event (a signal, for example) is observed.
>>
>> States and transits:
>>
>>   OFF--(on)--> READY --(toggle)--> TOGGLED --(process)--> PROCESSING
>>                  ^                    |                      |
>>                  |                    |                      |
>>                  |                 (ready)                (ready)
>>                  |                    |                      |
>>                   \__________________/______________________/
>>
>> is_toggled and is_ready are two key functions to query the state of
>> a trigger. is_toggled means the event already happen; is_ready means the
>> trigger is waiting for the event.
>>
>> 'PROCESSING' represents a state the event happens and be observed, and
>> the processing is on the way so can't accept a new event immediately.
> hum, I must be missing something.. but I dont see how you're
> using this state except for smal window within:
>
>                  if (auxtrace_snapshot_is_toggled()) {
>   ->                     auxtrace_snapshot_process();
>                          if (!auxtrace_snapshot_is_error())
>   ->                              record__read_auxtrace_snapshot(rec);
>
> but no other place queries or depends on this state

Right.

Since we are creating a new class, I think we can make code simpler by 
merging
all state variables into trigger.

Without this state we must keep 'auxtrace_record__snapshot_started'.

I think merging it into trigger class makes the whole program a little
bit simpler. Or do you think keeping trigger class simpler whould be better?

Thank you.

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


#1381756 — Re: [PATCH v4 1/6] perf tools: Derive trigger class from auxtrace_snapshot

FromJiri Olsa <jolsa@redhat.com>
Date2016-04-18 16:30 +0200
SubjectRe: [PATCH v4 1/6] perf tools: Derive trigger class from auxtrace_snapshot
Message-ID<rpilA-75e-25@gated-at.bofh.it>
In reply to#1381749
On Mon, Apr 18, 2016 at 10:20:23PM +0800, Wangnan (F) wrote:
> 
> 
> On 2016/4/18 21:45, Jiri Olsa wrote:
> >On Mon, Apr 18, 2016 at 06:32:08AM +0000, Wang Nan wrote:
> >>Use 'trigger' to model operations which need to be executed when
> >>an event (a signal, for example) is observed.
> >>
> >>States and transits:
> >>
> >>  OFF--(on)--> READY --(toggle)--> TOGGLED --(process)--> PROCESSING
> >>                 ^                    |                      |
> >>                 |                    |                      |
> >>                 |                 (ready)                (ready)
> >>                 |                    |                      |
> >>                  \__________________/______________________/
> >>
> >>is_toggled and is_ready are two key functions to query the state of
> >>a trigger. is_toggled means the event already happen; is_ready means the
> >>trigger is waiting for the event.
> >>
> >>'PROCESSING' represents a state the event happens and be observed, and
> >>the processing is on the way so can't accept a new event immediately.
> >hum, I must be missing something.. but I dont see how you're
> >using this state except for smal window within:
> >
> >                 if (auxtrace_snapshot_is_toggled()) {
> >  ->                     auxtrace_snapshot_process();
> >                         if (!auxtrace_snapshot_is_error())
> >  ->                              record__read_auxtrace_snapshot(rec);
> >
> >but no other place queries or depends on this state
> 
> Right.
> 
> Since we are creating a new class, I think we can make code simpler by
> merging
> all state variables into trigger.
> 
> Without this state we must keep 'auxtrace_record__snapshot_started'.

do we? we dont need this for switch_output code apparently

jirka

> 
> I think merging it into trigger class makes the whole program a little
> bit simpler. Or do you think keeping trigger class simpler whould be better?
> 
> Thank you.
> 
> 

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


#1381769 — Re: [PATCH v4 1/6] perf tools: Derive trigger class from auxtrace_snapshot

From"Wangnan (F)" <wangnan0@huawei.com>
Date2016-04-18 16:40 +0200
SubjectRe: [PATCH v4 1/6] perf tools: Derive trigger class from auxtrace_snapshot
Message-ID<rpivg-79W-41@gated-at.bofh.it>
In reply to#1381756

On 2016/4/18 22:29, Jiri Olsa wrote:
> On Mon, Apr 18, 2016 at 10:20:23PM +0800, Wangnan (F) wrote:
>>
>> On 2016/4/18 21:45, Jiri Olsa wrote:
>>> On Mon, Apr 18, 2016 at 06:32:08AM +0000, Wang Nan wrote:
>>>> Use 'trigger' to model operations which need to be executed when
>>>> an event (a signal, for example) is observed.
>>>>
>>>> States and transits:
>>>>
>>>>   OFF--(on)--> READY --(toggle)--> TOGGLED --(process)--> PROCESSING
>>>>                  ^                    |                      |
>>>>                  |                    |                      |
>>>>                  |                 (ready)                (ready)
>>>>                  |                    |                      |
>>>>                   \__________________/______________________/
>>>>
>>>> is_toggled and is_ready are two key functions to query the state of
>>>> a trigger. is_toggled means the event already happen; is_ready means the
>>>> trigger is waiting for the event.
>>>>
>>>> 'PROCESSING' represents a state the event happens and be observed, and
>>>> the processing is on the way so can't accept a new event immediately.
>>> hum, I must be missing something.. but I dont see how you're
>>> using this state except for smal window within:
>>>
>>>                  if (auxtrace_snapshot_is_toggled()) {
>>>   ->                     auxtrace_snapshot_process();
>>>                          if (!auxtrace_snapshot_is_error())
>>>   ->                              record__read_auxtrace_snapshot(rec);
>>>
>>> but no other place queries or depends on this state
>> Right.
>>
>> Since we are creating a new class, I think we can make code simpler by
>> merging
>> all state variables into trigger.
>>
>> Without this state we must keep 'auxtrace_record__snapshot_started'.
> do we? we dont need this for switch_output code apparently

I think it is a good chance to clean existing code.

However, number of lines introduced to .h in patch 1/6 is more than
lines removed from .c. So I think removing the 'PROCESSING' is okay.
If in future we find switch_output also need this state we can add it
back at that time.

Please wait for v5.

Thank you.

> jirka
>
>> I think merging it into trigger class makes the whole program a little
>> bit simpler. Or do you think keeping trigger class simpler whould be better?
>>
>> Thank you.
>>
>>

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


#1381291 — [PATCH v4 6/6] perf record: Generate tracking events for process forked by perf

FromWang Nan <wangnan0@huawei.com>
Date2016-04-18 08:40 +0200
Subject[PATCH v4 6/6] perf record: Generate tracking events for process forked by perf
Message-ID<rpb0K-WR-23@gated-at.bofh.it>
In reply to#1381287
With 'perf record --switch-output' without -a, record__synthesize() in
record__switch_output() won't generate tracking events because there's
no thread_map in evlist. Which causes newly created perf.data doesn't
contain map and comm information.

This patch creates a fake thread_map and directly call
perf_event__synthesize_thread_map() for those events.

Signed-off-by: Wang Nan <wangnan0@huawei.com>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Zefan Li <lizefan@huawei.com>
Cc: pi3orama@163.com
Link: http://lkml.kernel.org/r/1460643725-167413-7-git-send-email-wangnan0@huawei.com
Signed-off-by: He Kuang <hekuang@huawei.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
 tools/perf/builtin-record.c | 31 ++++++++++++++++++++++++++++++-
 1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 2965d83..0c6e201 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -500,6 +500,23 @@ record__finish_output(struct record *rec)
 	return;
 }
 
+static int record__synthesize_workload(struct record *rec)
+{
+	struct {
+		struct thread_map map;
+		struct thread_map_data map_data;
+	} thread_map;
+
+	thread_map.map.nr = 1;
+	thread_map.map.map[0].pid = rec->evlist->workload.pid;
+	thread_map.map.map[0].comm = NULL;
+	return perf_event__synthesize_thread_map(&rec->tool, &thread_map.map,
+						 process_synthesized_event,
+						 &rec->session->machines.host,
+						 rec->opts.sample_address,
+						 rec->opts.proc_map_timeout);
+}
+
 static int record__synthesize(struct record *rec);
 
 static int
@@ -532,9 +549,21 @@ record__switch_output(struct record *rec, bool at_exit)
 			file->path, timestamp);
 
 	/* Output tracking events */
-	if (!at_exit)
+	if (!at_exit) {
 		record__synthesize(rec);
 
+		/*
+		 * In 'perf record --switch-output' without -a,
+		 * record__synthesize() in record__switch_output() won't
+		 * generate tracking events because there's no thread_map
+		 * in evlist. Which causes newly created perf.data doesn't
+		 * contain map and comm information.
+		 * Create a fake thread_map and directly call
+		 * perf_event__synthesize_thread_map() for those events.
+		 */
+		if (target__none(&rec->opts.target))
+			record__synthesize_workload(rec);
+	}
 	return fd;
 }
 
-- 
1.8.3.4

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


#1381292 — [PATCH v4 5/6] perf record: Re-synthesize tracking events after output switching

FromWang Nan <wangnan0@huawei.com>
Date2016-04-18 08:40 +0200
Subject[PATCH v4 5/6] perf record: Re-synthesize tracking events after output switching
Message-ID<rpb0K-WR-21@gated-at.bofh.it>
In reply to#1381287
Tracking events describe kernel and threads. They are generated by
reading /proc/kallsyms, /proc/*/maps and /proc/*/task/* during
initialization of 'perf record', serialized into event sequences and put
at the head of 'perf.data'. In case of output switching, each output
file should contain those events.

This patch calls record__synthesize() during output switching, so the
event sequences described above can be collected again.

Signed-off-by: Wang Nan <wangnan0@huawei.com>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: He Kuang <hekuang@huawei.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Zefan Li <lizefan@huawei.com>
Cc: pi3orama@163.com
Link: http://lkml.kernel.org/r/1460643725-167413-6-git-send-email-wangnan0@huawei.com
Signed-off-by: He Kuang <hekuang@huawei.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
 tools/perf/builtin-record.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 743af13..2965d83 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -500,6 +500,8 @@ record__finish_output(struct record *rec)
 	return;
 }
 
+static int record__synthesize(struct record *rec);
+
 static int
 record__switch_output(struct record *rec, bool at_exit)
 {
@@ -528,6 +530,11 @@ record__switch_output(struct record *rec, bool at_exit)
 	if (!quiet)
 		fprintf(stderr, "[ perf record: Dump %s.%s ]\n",
 			file->path, timestamp);
+
+	/* Output tracking events */
+	if (!at_exit)
+		record__synthesize(rec);
+
 	return fd;
 }
 
-- 
1.8.3.4

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


#1381295 — [PATCH v4 4/6] perf record: Disable buildid cache options by default in switch output mode

FromWang Nan <wangnan0@huawei.com>
Date2016-04-18 08:40 +0200
Subject[PATCH v4 4/6] perf record: Disable buildid cache options by default in switch output mode
Message-ID<rpb0L-WR-35@gated-at.bofh.it>
In reply to#1381287
The cost of buildid cache processing is high: reading all events in
output perf.data, opening each elf file to read buildids then copying
them into ~/.debug directory. In switch output mode, these heavy works
block perf from receiving perf events for too long.

Enable no-buildid and no-buildid-cache by default if --switch-output
is provided. Still allow user use --no-no-buildid to explicitly enable
buildid in this case.

Signed-off-by: Wang Nan <wangnan0@huawei.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Zefan Li <lizefan@huawei.com>
Cc: pi3orama@163.com
Link: http://lkml.kernel.org/r/1460643725-167413-5-git-send-email-wangnan0@huawei.com
Signed-off-by: He Kuang <hekuang@huawei.com>
[ Updated man page ]
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
 tools/perf/Documentation/perf-record.txt |  2 +-
 tools/perf/builtin-record.c              | 30 +++++++++++++++++++++++++++++-
 2 files changed, 30 insertions(+), 2 deletions(-)

diff --git a/tools/perf/Documentation/perf-record.txt b/tools/perf/Documentation/perf-record.txt
index 79a8a14..8dbee83 100644
--- a/tools/perf/Documentation/perf-record.txt
+++ b/tools/perf/Documentation/perf-record.txt
@@ -358,7 +358,7 @@ A possible use case is to, given an external event, slice the perf.data file
 that gets then processed, possibly via a perf script, to decide if that
 particular perf.data snapshot should be kept or not.
 
-Implies --timestamp-filename.
+Implies --timestamp-filename, --no-buildid and --no-buildid-cache.
 
 SEE ALSO
 --------
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index c389d52..743af13 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -1382,8 +1382,36 @@ int cmd_record(int argc, const char **argv, const char *prefix __maybe_unused)
 "If some relocation was applied (e.g. kexec) symbols may be misresolved\n"
 "even with a suitable vmlinux or kallsyms file.\n\n");
 
-	if (rec->no_buildid_cache || rec->no_buildid)
+	if (rec->no_buildid_cache || rec->no_buildid) {
 		disable_buildid_cache();
+	} else if (rec->switch_output) {
+		/*
+		 * In 'perf record --switch-output', disable buildid
+		 * generation by default to reduce data file switching
+		 * overhead. Still generate buildid if they are required
+		 * explicitly using
+		 *
+		 *  perf record --signal-trigger --no-no-buildid \
+		 *              --no-no-buildid-cache
+		 *
+		 * Following code equals to:
+		 *
+		 * if ((rec->no_buildid || !rec->no_buildid_set) &&
+		 *     (rec->no_buildid_cache || !rec->no_buildid_cache_set))
+		 *         disable_buildid_cache();
+		 */
+		bool disable = true;
+
+		if (rec->no_buildid_set && !rec->no_buildid)
+			disable = false;
+		if (rec->no_buildid_cache_set && !rec->no_buildid_cache)
+			disable = false;
+		if (disable) {
+			rec->no_buildid = true;
+			rec->no_buildid_cache = true;
+			disable_buildid_cache();
+		}
+	}
 
 	if (rec->evlist->nr_entries == 0 &&
 	    perf_evlist__add_default(rec->evlist) < 0) {
-- 
1.8.3.4

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web