[PATCH] tools, perf: Allow the user to disable time stamps

[PATCH] tools, perf: Allow the user to disable time stamps

[Andi Kleen]

From: Andi Kleen <ak@linux.intel.com>

Time stamps are always implicitely enabled for record currently.
The old --time/-T option is a nop.

Allow the user to disable timestamps by using --no-time

This can cause some minor misaccounting (by missing mmaps), but significantly
lowers the size of perf.data

The defaults are unchanged.

Signed-off-by: Andi Kleen <ak@linux.intel.com>
---
 tools/perf/builtin-record.c | 1 +
 tools/perf/util/evsel.c     | 9 ++++++---
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 3c394bf..8e92d3c 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -800,6 +800,7 @@ static const char * const record_usage[] = {
  */
 static struct record record = {
 	.opts = {
+		.sample_time	     = true,
 		.mmap_pages	     = UINT_MAX,
 		.user_freq	     = UINT_MAX,
 		.user_interval	     = ULLONG_MAX,
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 22e18a2..a15efc4 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -613,9 +613,12 @@ void perf_evsel__config(struct perf_evsel *evsel, struct record_opts *opts)
 	if (opts->period)
 		perf_evsel__set_sample_bit(evsel, PERIOD);
 
-	if (!perf_missing_features.sample_id_all &&
-	    (opts->sample_time || !opts->no_inherit ||
-	     target__has_cpu(&opts->target) || per_cpu))
+	/*
+	 * When the user explicitely disabled time don't force it here.
+	 */
+	if (opts->sample_time &&
+	    (!perf_missing_features.sample_id_all &&
+	    (!opts->no_inherit || target__has_cpu(&opts->target) || per_cpu)))
 		perf_evsel__set_sample_bit(evsel, TIME);
 
 	if (opts->raw_samples) {
-- 
1.8.5.3

[PATCH] tools, perf: Allow the user to disable time stamps

[Andi Kleen]

From: Andi Kleen <ak@linux.intel.com>

[post with updated description]

Time stamps are always implicitely enabled for record currently.
The old --time/-T option is a nop.

The time stamps are needed to handle library mmaps correctly.
This mainly matters at program startup, but is not useful
when profiling long running programs.

Allow the user to disable timestamps by using --no-time

This can cause some minor misaccounting, but lowers the
size of the perf.data nicely:

% perl -e 'while(1) {}' &
[1] 5827
% perf record -p 5827 --no-time -c 1000003 sleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.089 MB perf.data (~3872 samples) ]
% perf record -p 5827  -c 1000003  sleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.114 MB perf.data (~4967 samples) ]

22% smaller data file, even though we got more samples.
It also seems to speed up perf slightly, that is why we get more
samples.

The defaults are unchanged.

Signed-off-by: Andi Kleen <ak@linux.intel.com>
---
 tools/perf/builtin-record.c | 1 +
 tools/perf/util/evsel.c     | 9 ++++++---
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 3c394bf..8e92d3c 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -800,6 +800,7 @@ static const char * const record_usage[] = {
  */
 static struct record record = {
 	.opts = {
+		.sample_time	     = true,
 		.mmap_pages	     = UINT_MAX,
 		.user_freq	     = UINT_MAX,
 		.user_interval	     = ULLONG_MAX,
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 22e18a2..a15efc4 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -613,9 +613,12 @@ void perf_evsel__config(struct perf_evsel *evsel, struct record_opts *opts)
 	if (opts->period)
 		perf_evsel__set_sample_bit(evsel, PERIOD);
 
-	if (!perf_missing_features.sample_id_all &&
-	    (opts->sample_time || !opts->no_inherit ||
-	     target__has_cpu(&opts->target) || per_cpu))
+	/*
+	 * When the user explicitely disabled time don't force it here.
+	 */
+	if (opts->sample_time &&
+	    (!perf_missing_features.sample_id_all &&
+	    (!opts->no_inherit || target__has_cpu(&opts->target) || per_cpu)))
 		perf_evsel__set_sample_bit(evsel, TIME);
 
 	if (opts->raw_samples) {
-- 
1.8.5.3

Re: [PATCH] tools, perf: Allow the user to disable time stamps

[Stephane Eranian]

On Tue, Mar 25, 2014 at 9:44 PM, Andi Kleen <andi@firstfloor.org> wrote:
>
> From: Andi Kleen <ak@linux.intel.com>
>
> [post with updated description]
>
> Time stamps are always implicitely enabled for record currently.
> The old --time/-T option is a nop.
>
> The time stamps are needed to handle library mmaps correctly.
> This mainly matters at program startup, but is not useful
> when profiling long running programs.
>
> Allow the user to disable timestamps by using --no-time
>
> This can cause some minor misaccounting, but lowers the
> size of the perf.data nicely:
>
> % perl -e 'while(1) {}' &
> [1] 5827
> % perf record -p 5827 --no-time -c 1000003 sleep 1
> [ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 0.089 MB perf.data (~3872 samples) ]
> % perf record -p 5827  -c 1000003  sleep 1
> [ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 0.114 MB perf.data (~4967 samples) ]
>
> 22% smaller data file, even though we got more samples.
> It also seems to speed up perf slightly, that is why we get more
> samples.
>
But that measure of the number of samples is bogus most of the time.
It is an estimate based on a standard sample size.

Timestamp are useful to order samples during reporting.
How do you do with it if you monitor multi-threaded (multi-cpu)
workloads. This is only good for single thread or single CPU
measurements. Or am I missing something?


>
> The defaults are unchanged.
>
> Signed-off-by: Andi Kleen <ak@linux.intel.com>
> ---
>  tools/perf/builtin-record.c | 1 +
>  tools/perf/util/evsel.c     | 9 ++++++---
>  2 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
> index 3c394bf..8e92d3c 100644
> --- a/tools/perf/builtin-record.c
> +++ b/tools/perf/builtin-record.c
> @@ -800,6 +800,7 @@ static const char * const record_usage[] = {
>   */
>  static struct record record = {
>         .opts = {
> +               .sample_time         = true,
>                 .mmap_pages          = UINT_MAX,
>                 .user_freq           = UINT_MAX,
>                 .user_interval       = ULLONG_MAX,
> diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
> index 22e18a2..a15efc4 100644
> --- a/tools/perf/util/evsel.c
> +++ b/tools/perf/util/evsel.c
> @@ -613,9 +613,12 @@ void perf_evsel__config(struct perf_evsel *evsel, struct record_opts *opts)
>         if (opts->period)
>                 perf_evsel__set_sample_bit(evsel, PERIOD);
>
> -       if (!perf_missing_features.sample_id_all &&
> -           (opts->sample_time || !opts->no_inherit ||
> -            target__has_cpu(&opts->target) || per_cpu))
> +       /*
> +        * When the user explicitely disabled time don't force it here.
> +        */
> +       if (opts->sample_time &&
> +           (!perf_missing_features.sample_id_all &&
> +           (!opts->no_inherit || target__has_cpu(&opts->target) || per_cpu)))
>                 perf_evsel__set_sample_bit(evsel, TIME);
>
>         if (opts->raw_samples) {
> --
> 1.8.5.3
>

Re: [PATCH] tools, perf: Allow the user to disable time stamps

[Andi Kleen]

> 
> Timestamp are useful to order samples during reporting.
> How do you do with it if you monitor multi-threaded (multi-cpu)
> workloads. This is only good for single thread or single CPU
> measurements. Or am I missing something?

For a perf report order doesn't matter (except against mmaps)
The CPUs are still separated of course

You're right for some special analysis it matters, that is why
it is only an option. 

But for the standard "only care about perf report and 
don't care about about program startup" case it's a nice saving.

-Andi

Re: [PATCH] tools, perf: Allow the user to disable time stamps

[Andi Kleen]

Also here's updated data with ls -lh. 24% saving here.
The perf output is actually not that inaccurate
for this case.

% perf record  --no-time -c 100003 -p 10247 sleep 1
% ls -lh perf.data
-rw------- 1 ak users 681K Mar 25 14:04 perf.data
% perf record  -c 100003 -p 10247 sleep 1
[ perf record: Woken up 4 times to write data ]
[ perf record: Captured and wrote 0.869 MB perf.data (~37982 samples) ]
% ls -lh perf.data
-rw------- 1 ak users 893K Mar 25 14:04 perf.data

-Andi

Re: [PATCH] tools, perf: Allow the user to disable time stamps

[Stephane Eranian]

On Tue, Mar 25, 2014 at 10:01 PM, Andi Kleen <ak@linux.intel.com> wrote:
>>
>> Timestamp are useful to order samples during reporting.
>> How do you do with it if you monitor multi-threaded (multi-cpu)
>> workloads. This is only good for single thread or single CPU
>> measurements. Or am I missing something?
>
> For a perf report order doesn't matter (except against mmaps)
> The CPUs are still separated of course
>
But getting the mmaps at the right moment is crucial for some apps
especially if address space is recycled otherwise symbolization
may be incorrect.

> You're right for some special analysis it matters, that is why
> it is only an option.
>
> But for the standard "only care about perf report and
> don't care about about program startup" case it's a nice saving.
>
How do you know in advance you won't need mmap ordering?

Re: [PATCH] tools, perf: Allow the user to disable time stamps

[Andi Kleen]

Stephane Eranian <eranian@google.com> writes:
>>
> But getting the mmaps at the right moment is crucial for some apps
> especially if address space is recycled otherwise symbolization
> may be incorrect.

Yes that is why it is only an option and not default.
You need to know what you're doing.

BTW I think the recycle case is not very likely on non JIT.

>> You're right for some special analysis it matters, that is why
>> it is only an option.
>>
>> But for the standard "only care about perf report and
>> don't care about about program startup" case it's a nice saving.
>>
> How do you know in advance you won't need mmap ordering?

When I measure a long running process and I know it doesn't
fork/dlopen/jit. Using --initial-delay also helps to skip
the startup phase or attaching later.

I believe it's actually a good choice for most non
forky workloads. But yes it cannot be made default.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only