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

Groups > linux.kernel > #1232796 > unrolled thread

[PATCH 15/25] perf report: Make max_stack value allow for synthesized callchains

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH 15/25] perf report: Make max_stack value allow for synthesized callchains Adrian Hunter <adrian.hunter@intel.com> - 2015-09-25 15:20 +0200
    Re: [PATCH 15/25] perf report: Make max_stack value allow for  synthesized callchains Arnaldo Carvalho de Melo <acme@kernel.org> - 2015-09-28 22:10 +0200
      Re: [PATCH 15/25] perf report: Make max_stack value allow for  synthesized callchains Adrian Hunter <adrian.hunter@intel.com> - 2015-09-29 11:00 +0200
        Re: [PATCH 15/25] perf report: Make max_stack value allow for  synthesized callchains Arnaldo Carvalho de Melo <acme@kernel.org> - 2015-09-29 18:00 +0200
          Re: [PATCH 15/25] perf report: Make max_stack value allow for  synthesized callchains Adrian Hunter <adrian.hunter@intel.com> - 2015-09-30 10:50 +0200
            Re: [PATCH 15/25] perf report: Make max_stack value allow for  synthesized callchains Arnaldo Carvalho de Melo <acme@kernel.org> - 2015-09-30 15:20 +0200
        [tip:perf/core] perf report:   Amend documentation about max_stack and synthesized callchains tip-bot for Adrian Hunter <tipbot@zytor.com> - 2015-10-01 09:20 +0200
    [tip:perf/core] perf report:   Make max_stack value allow for synthesized callchains tip-bot for Adrian Hunter <tipbot@zytor.com> - 2015-09-29 10:50 +0200

#1232796 — [PATCH 15/25] perf report: Make max_stack value allow for synthesized callchains

perf report has an option (--max-stack) to set the maximum stack depth
when processing callchains.  The option defaults to the hard-coded
maximum definition PERF_MAX_STACK_DEPTH which is 127.  The intention of
the option is to allow the user to reduce the processing time by
reducing the amount of the callchain that is processed.

It is also possible, when processing instruction traces, to synthesize
callchains.  Synthesized callchains do not have the kernel size
limitation and are whatever size the user requests, although validation
presently prevents the user requested a value greater that 1024.  The
default value is 16.

To allow for synthesized callchains, make the max_stack value at least
the same size as the synthesized callchain size.

Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
---
 tools/perf/builtin-report.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index e94e5c7155af..37c9f5125887 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -809,6 +809,10 @@ int cmd_report(int argc, const char **argv, const char *prefix __maybe_unused)
 	if (report.inverted_callchain)
 		callchain_param.order = ORDER_CALLER;
 
+	if (itrace_synth_opts.callchain &&
+	    (int)itrace_synth_opts.callchain_sz > report.max_stack)
+		report.max_stack = itrace_synth_opts.callchain_sz;
+
 	if (!input_name || !strlen(input_name)) {
 		if (!fstat(STDIN_FILENO, &st) && S_ISFIFO(st.st_mode))
 			input_name = "-";
-- 
1.9.1

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

[toc] | [next] | [standalone]

#1234408 — Re: [PATCH 15/25] perf report: Make max_stack value allow for synthesized callchains

Em Fri, Sep 25, 2015 at 04:15:46PM +0300, Adrian Hunter escreveu:
> perf report has an option (--max-stack) to set the maximum stack depth
> when processing callchains.  The option defaults to the hard-coded
> maximum definition PERF_MAX_STACK_DEPTH which is 127.  The intention of
> the option is to allow the user to reduce the processing time by
> reducing the amount of the callchain that is processed.
> 
> It is also possible, when processing instruction traces, to synthesize
> callchains.  Synthesized callchains do not have the kernel size
> limitation and are whatever size the user requests, although validation
> presently prevents the user requested a value greater that 1024.  The
> default value is 16.

So, haven't checked the options, but one can possibly use both the way
itrace has to ask for a max stack size and also via --max-stack, right?

In that case we better emit a warning or plain state that one either
uses one way of setting the max stack or the other?

I'm applying the patch, because it is unlikely that this gets specified,
but would be good to close this gap.

- Arnaldo
 
> To allow for synthesized callchains, make the max_stack value at least
> the same size as the synthesized callchain size.
> 
> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
> ---
>  tools/perf/builtin-report.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
> index e94e5c7155af..37c9f5125887 100644
> --- a/tools/perf/builtin-report.c
> +++ b/tools/perf/builtin-report.c
> @@ -809,6 +809,10 @@ int cmd_report(int argc, const char **argv, const char *prefix __maybe_unused)
>  	if (report.inverted_callchain)
>  		callchain_param.order = ORDER_CALLER;
>  
> +	if (itrace_synth_opts.callchain &&
> +	    (int)itrace_synth_opts.callchain_sz > report.max_stack)
> +		report.max_stack = itrace_synth_opts.callchain_sz;
> +
>  	if (!input_name || !strlen(input_name)) {
>  		if (!fstat(STDIN_FILENO, &st) && S_ISFIFO(st.st_mode))
>  			input_name = "-";
> -- 
> 1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1234877 — Re: [PATCH 15/25] perf report: Make max_stack value allow for synthesized callchains

On 28/09/15 23:03, Arnaldo Carvalho de Melo wrote:
> Em Fri, Sep 25, 2015 at 04:15:46PM +0300, Adrian Hunter escreveu:
>> perf report has an option (--max-stack) to set the maximum stack depth
>> when processing callchains.  The option defaults to the hard-coded
>> maximum definition PERF_MAX_STACK_DEPTH which is 127.  The intention of
>> the option is to allow the user to reduce the processing time by
>> reducing the amount of the callchain that is processed.
>>
>> It is also possible, when processing instruction traces, to synthesize
>> callchains.  Synthesized callchains do not have the kernel size
>> limitation and are whatever size the user requests, although validation
>> presently prevents the user requested a value greater that 1024.  The
>> default value is 16.
> 
> So, haven't checked the options, but one can possibly use both the way
> itrace has to ask for a max stack size and also via --max-stack, right?

Possibly, but it would not be a common paradigm.

> 
> In that case we better emit a warning or plain state that one either
> uses one way of setting the max stack or the other?

max_stack was added as an optimization to reduce processing time, so
people specifying --max-stack might get a increased processing time
if combined with synthesized callchains, but otherwise no real harm.

A warning seems like overkill.  Could amend the documenation e.g.


diff --git a/tools/perf/Documentation/perf-report.txt b/tools/perf/Documentation/perf-report.txt
index b941d5e07e28..ce499035e6d8 100644
--- a/tools/perf/Documentation/perf-report.txt
+++ b/tools/perf/Documentation/perf-report.txt
@@ -205,6 +205,8 @@ OPTIONS
 	beyond the specified depth will be ignored. This is a trade-off
 	between information loss and faster processing especially for
 	workloads that can have a very long callchain stack.
+	Note that when using the --itrace option the synthesized callchain size
+	will override this value if the synthesized callchain size is bigger.
 
 	Default: 127
 



> 
> I'm applying the patch, because it is unlikely that this gets specified,
> but would be good to close this gap.
> 
> - Arnaldo
>  
>> To allow for synthesized callchains, make the max_stack value at least
>> the same size as the synthesized callchain size.
>>
>> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
>> ---
>>  tools/perf/builtin-report.c | 4 ++++
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
>> index e94e5c7155af..37c9f5125887 100644
>> --- a/tools/perf/builtin-report.c
>> +++ b/tools/perf/builtin-report.c
>> @@ -809,6 +809,10 @@ int cmd_report(int argc, const char **argv, const char *prefix __maybe_unused)
>>  	if (report.inverted_callchain)
>>  		callchain_param.order = ORDER_CALLER;
>>  
>> +	if (itrace_synth_opts.callchain &&
>> +	    (int)itrace_synth_opts.callchain_sz > report.max_stack)
>> +		report.max_stack = itrace_synth_opts.callchain_sz;
>> +
>>  	if (!input_name || !strlen(input_name)) {
>>  		if (!fstat(STDIN_FILENO, &st) && S_ISFIFO(st.st_mode))
>>  			input_name = "-";
>> -- 
>> 1.9.1
> 

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

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

#1235335 — Re: [PATCH 15/25] perf report: Make max_stack value allow for synthesized callchains

Em Tue, Sep 29, 2015 at 11:52:37AM +0300, Adrian Hunter escreveu:
> On 28/09/15 23:03, Arnaldo Carvalho de Melo wrote:
> > Em Fri, Sep 25, 2015 at 04:15:46PM +0300, Adrian Hunter escreveu:
> >> perf report has an option (--max-stack) to set the maximum stack depth
> >> when processing callchains.  The option defaults to the hard-coded
> >> maximum definition PERF_MAX_STACK_DEPTH which is 127.  The intention of
> >> the option is to allow the user to reduce the processing time by
> >> reducing the amount of the callchain that is processed.
> >>
> >> It is also possible, when processing instruction traces, to synthesize
> >> callchains.  Synthesized callchains do not have the kernel size
> >> limitation and are whatever size the user requests, although validation
> >> presently prevents the user requested a value greater that 1024.  The
> >> default value is 16.
> > 
> > So, haven't checked the options, but one can possibly use both the way
> > itrace has to ask for a max stack size and also via --max-stack, right?
> 
> Possibly, but it would not be a common paradigm.
> 
> > 
> > In that case we better emit a warning or plain state that one either
> > uses one way of setting the max stack or the other?
> 
> max_stack was added as an optimization to reduce processing time, so
> people specifying --max-stack might get a increased processing time
> if combined with synthesized callchains, but otherwise no real harm.
> 
> A warning seems like overkill.  Could amend the documenation e.g.

Adding the doc part helps, but actually telling that what they are
trying to do is not possible, even for unlikely scenarios like this,
seems cleaner, but no biggie.

I'll add the patch below with your s-o-b, ack?

- Arnaldo
 
> 
> diff --git a/tools/perf/Documentation/perf-report.txt b/tools/perf/Documentation/perf-report.txt
> index b941d5e07e28..ce499035e6d8 100644
> --- a/tools/perf/Documentation/perf-report.txt
> +++ b/tools/perf/Documentation/perf-report.txt
> @@ -205,6 +205,8 @@ OPTIONS
>  	beyond the specified depth will be ignored. This is a trade-off
>  	between information loss and faster processing especially for
>  	workloads that can have a very long callchain stack.
> +	Note that when using the --itrace option the synthesized callchain size
> +	will override this value if the synthesized callchain size is bigger.
>  
>  	Default: 127
>  
> 
> 
> 
> > 
> > I'm applying the patch, because it is unlikely that this gets specified,
> > but would be good to close this gap.
> > 
> > - Arnaldo
> >  
> >> To allow for synthesized callchains, make the max_stack value at least
> >> the same size as the synthesized callchain size.
> >>
> >> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
> >> ---
> >>  tools/perf/builtin-report.c | 4 ++++
> >>  1 file changed, 4 insertions(+)
> >>
> >> diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
> >> index e94e5c7155af..37c9f5125887 100644
> >> --- a/tools/perf/builtin-report.c
> >> +++ b/tools/perf/builtin-report.c
> >> @@ -809,6 +809,10 @@ int cmd_report(int argc, const char **argv, const char *prefix __maybe_unused)
> >>  	if (report.inverted_callchain)
> >>  		callchain_param.order = ORDER_CALLER;
> >>  
> >> +	if (itrace_synth_opts.callchain &&
> >> +	    (int)itrace_synth_opts.callchain_sz > report.max_stack)
> >> +		report.max_stack = itrace_synth_opts.callchain_sz;
> >> +
> >>  	if (!input_name || !strlen(input_name)) {
> >>  		if (!fstat(STDIN_FILENO, &st) && S_ISFIFO(st.st_mode))
> >>  			input_name = "-";
> >> -- 
> >> 1.9.1
> > 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1235903 — Re: [PATCH 15/25] perf report: Make max_stack value allow for synthesized callchains

On 29/09/15 18:51, Arnaldo Carvalho de Melo wrote:
> Em Tue, Sep 29, 2015 at 11:52:37AM +0300, Adrian Hunter escreveu:
>> On 28/09/15 23:03, Arnaldo Carvalho de Melo wrote:
>>> Em Fri, Sep 25, 2015 at 04:15:46PM +0300, Adrian Hunter escreveu:
>>>> perf report has an option (--max-stack) to set the maximum stack depth
>>>> when processing callchains.  The option defaults to the hard-coded
>>>> maximum definition PERF_MAX_STACK_DEPTH which is 127.  The intention of
>>>> the option is to allow the user to reduce the processing time by
>>>> reducing the amount of the callchain that is processed.
>>>>
>>>> It is also possible, when processing instruction traces, to synthesize
>>>> callchains.  Synthesized callchains do not have the kernel size
>>>> limitation and are whatever size the user requests, although validation
>>>> presently prevents the user requested a value greater that 1024.  The
>>>> default value is 16.
>>>
>>> So, haven't checked the options, but one can possibly use both the way
>>> itrace has to ask for a max stack size and also via --max-stack, right?
>>
>> Possibly, but it would not be a common paradigm.
>>
>>>
>>> In that case we better emit a warning or plain state that one either
>>> uses one way of setting the max stack or the other?
>>
>> max_stack was added as an optimization to reduce processing time, so
>> people specifying --max-stack might get a increased processing time
>> if combined with synthesized callchains, but otherwise no real harm.
>>
>> A warning seems like overkill.  Could amend the documenation e.g.
> 
> Adding the doc part helps, but actually telling that what they are
> trying to do is not possible, even for unlikely scenarios like this,
> seems cleaner, but no biggie.
> 
> I'll add the patch below with your s-o-b, ack?

Yes thank you.

> 
> - Arnaldo
>  
>>
>> diff --git a/tools/perf/Documentation/perf-report.txt b/tools/perf/Documentation/perf-report.txt
>> index b941d5e07e28..ce499035e6d8 100644
>> --- a/tools/perf/Documentation/perf-report.txt
>> +++ b/tools/perf/Documentation/perf-report.txt
>> @@ -205,6 +205,8 @@ OPTIONS
>>  	beyond the specified depth will be ignored. This is a trade-off
>>  	between information loss and faster processing especially for
>>  	workloads that can have a very long callchain stack.
>> +	Note that when using the --itrace option the synthesized callchain size
>> +	will override this value if the synthesized callchain size is bigger.
>>  
>>  	Default: 127
>>  
>>
>>
>>
>>>
>>> I'm applying the patch, because it is unlikely that this gets specified,
>>> but would be good to close this gap.
>>>
>>> - Arnaldo
>>>  
>>>> To allow for synthesized callchains, make the max_stack value at least
>>>> the same size as the synthesized callchain size.
>>>>
>>>> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
>>>> ---
>>>>  tools/perf/builtin-report.c | 4 ++++
>>>>  1 file changed, 4 insertions(+)
>>>>
>>>> diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
>>>> index e94e5c7155af..37c9f5125887 100644
>>>> --- a/tools/perf/builtin-report.c
>>>> +++ b/tools/perf/builtin-report.c
>>>> @@ -809,6 +809,10 @@ int cmd_report(int argc, const char **argv, const char *prefix __maybe_unused)
>>>>  	if (report.inverted_callchain)
>>>>  		callchain_param.order = ORDER_CALLER;
>>>>  
>>>> +	if (itrace_synth_opts.callchain &&
>>>> +	    (int)itrace_synth_opts.callchain_sz > report.max_stack)
>>>> +		report.max_stack = itrace_synth_opts.callchain_sz;
>>>> +
>>>>  	if (!input_name || !strlen(input_name)) {
>>>>  		if (!fstat(STDIN_FILENO, &st) && S_ISFIFO(st.st_mode))
>>>>  			input_name = "-";
>>>> -- 
>>>> 1.9.1
>>>
> 

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

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

#1236276 — Re: [PATCH 15/25] perf report: Make max_stack value allow for synthesized callchains

Em Wed, Sep 30, 2015 at 11:43:10AM +0300, Adrian Hunter escreveu:
> On 29/09/15 18:51, Arnaldo Carvalho de Melo wrote:
> > I'll add the patch below with your s-o-b, ack?
> 
> Yes thank you.

Done, pushed out.

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

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

#1237069 — [tip:perf/core] perf report: Amend documentation about max_stack and synthesized callchains

Commit-ID:  40862a7b793945c7080d1566ca3dc6249f3c6354
Gitweb:     http://git.kernel.org/tip/40862a7b793945c7080d1566ca3dc6249f3c6354
Author:     Adrian Hunter <adrian.hunter@intel.com>
AuthorDate: Tue, 29 Sep 2015 11:52:37 +0300
Committer:  Arnaldo Carvalho de Melo <acme@redhat.com>
CommitDate: Wed, 30 Sep 2015 18:34:26 -0300

perf report: Amend documentation about max_stack and synthesized callchains

The --max_stack option was added as an optimization to reduce processing time,
so people specifying --max-stack might get a increased processing time if
combined with synthesized callchains, but otherwise no real harm.

A warning about setting both --max_stack and the synthesized callchains max
depth seems like overkill.  Amend the documentation.

Reported-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Link: http://lkml.kernel.org/r/560A5155.4060105@intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
 tools/perf/Documentation/perf-report.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/perf/Documentation/perf-report.txt b/tools/perf/Documentation/perf-report.txt
index b941d5e..ce49903 100644
--- a/tools/perf/Documentation/perf-report.txt
+++ b/tools/perf/Documentation/perf-report.txt
@@ -205,6 +205,8 @@ OPTIONS
 	beyond the specified depth will be ignored. This is a trade-off
 	between information loss and faster processing especially for
 	workloads that can have a very long callchain stack.
+	Note that when using the --itrace option the synthesized callchain size
+	will override this value if the synthesized callchain size is bigger.
 
 	Default: 127
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1234851 — [tip:perf/core] perf report: Make max_stack value allow for synthesized callchains

Commit-ID:  188bb5e2ce112463428994f91291e5df6fc05521
Gitweb:     http://git.kernel.org/tip/188bb5e2ce112463428994f91291e5df6fc05521
Author:     Adrian Hunter <adrian.hunter@intel.com>
AuthorDate: Fri, 25 Sep 2015 16:15:46 +0300
Committer:  Arnaldo Carvalho de Melo <acme@redhat.com>
CommitDate: Mon, 28 Sep 2015 17:03:20 -0300

perf report: Make max_stack value allow for synthesized callchains

perf report has an option (--max-stack) to set the maximum stack depth
when processing callchains.  The option defaults to the hard-coded
maximum definition PERF_MAX_STACK_DEPTH which is 127.  The intention of
the option is to allow the user to reduce the processing time by
reducing the amount of the callchain that is processed.

It is also possible, when processing instruction traces, to synthesize
callchains.  Synthesized callchains do not have the kernel size
limitation and are whatever size the user requests, although validation
presently prevents the user requested a value greater that 1024.  The
default value is 16.

To allow for synthesized callchains, make the max_stack value at least
the same size as the synthesized callchain size.

Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Link: http://lkml.kernel.org/r/1443186956-18718-16-git-send-email-adrian.hunter@intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
 tools/perf/builtin-report.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index e94e5c7..37c9f51 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -809,6 +809,10 @@ int cmd_report(int argc, const char **argv, const char *prefix __maybe_unused)
 	if (report.inverted_callchain)
 		callchain_param.order = ORDER_CALLER;
 
+	if (itrace_synth_opts.callchain &&
+	    (int)itrace_synth_opts.callchain_sz > report.max_stack)
+		report.max_stack = itrace_synth_opts.callchain_sz;
+
 	if (!input_name || !strlen(input_name)) {
 		if (!fstat(STDIN_FILENO, &st) && S_ISFIFO(st.st_mode))
 			input_name = "-";
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web