Message-ID: <20150309081736.GA943@sejong>
Date:	Mon, 9 Mar 2015 17:17:36 +0900
From:	Namhyung Kim <namhyung@...nel.org>
To:	Taeung <treeze.taeung@...il.com>
Cc:	linux-kernel@...r.kernel.org,
	Arnaldo Carvalho de Melo <acme@...nel.org>,
	jolsa@...nel.org
Subject: Re: [PATCH] perf config : Adding a command 'config' with a option
 '--list' and a document for it.

Hi Taeung,

(Please add Jiri to CC when sending a patch for perf tools..)

Thanks for doing this.  I left some more description and suggestion
from my understanding, I think other guys will provide more helpful
and clear words on other parts.


On Sat, Mar 07, 2015 at 09:30:05PM +0900, Taeung wrote:
> The perf configuration file contain many variables which can make
> the perf command's action more effective and more skilful.
> But looking through state of configuration is difficult and
> there's no knowing what kind of other variables except variables in perfconfig.example exist.
> So This patch adds a command 'config --list' and a document for it.
> ---

[SNIP]
> +Variables
> +~~~~~~~~~
> +
> +colors.*::
> +	Color variables can appoint colors of the output which is printed out 
> +	from ‘report’, ‘top’,’annotate’ on tui.
> +	Color variables is composed of foreground and background
> +	and should have two values for them. If you want to set as colors 
> +	of your terminal, you should use ‘default’ for color value.
> +        The kind of color which can be used as below.
> +	red, green, default, black, blue, white, magenta, lightgray
> +	
> +	colors.top::
> +		‘top’ means a overhead percentage which has more than 5%.
> +		And values of it’s variable specify colors of percentage.
> +		Basic key values are foreground-color ’red’ and 
> +		background-color ’default’.
> +	colors.medium::
> +		‘medium’ means a overhead percentage which has more than 0.5%. 
> +		Default values are ’green’ and ’default’.
> +	colors.normal::
> +		‘normal’ means rest of overhead percentages 
> +		except ‘top’, ‘medium’, ‘selected’.
> +		Default values are ’lightgray’ and ’default’.
> +	colors.selected::
> +		This appoint colors for forcussed one of the output list 
> +		from sub-commands (top,report,annotate).  
> +		Default values are ’white’ and ’lightgray’.
> +	colors.code:: 
> +		Colors for a arrow and lines on jumping by assembly code 
> +		such as ‘jns’,’jmp’,’jane’,etc. Default values are ‘blue’, ‘default’.
> +	colors.addr::
> +		This appoint colors for addresses from a sub-command ’annotate’.
> +		Default values are ‘magenta’, ‘default’.
> +	colors.root::
> +		Colors for headers in the output of a sub-command ‘top’. 
> +		Default values are ‘white’, ‘blue’.
> +
> +tui.*::
> +	Using sub-commands which are ’top’ and ‘report’, ‘annotate’,
> +	declare whether they work on TUI or not by ‘on’ or ‘off’.

How about this:

	A boolean value that controls launching TUI browser for each subcommand.
	By default, TUI is enabled if perf detects a needed library during build
	and this config option can control it.  Available subcommands are 'top',
	'report' and 'annotate'.


> +gtk.*::
> +	Using sub-commands which are ’top’ and ‘report’, ‘annotate’,
> +	declare whether they work on GTK or not by ‘on’ or ‘off’. 

Ditto:

	A boolean value that controls launching GTK+2 GUI browser for
	each subcommand.  By default, TUI is enabled if perf detects a
	needed library during build and this config option can control
	it.  Available subcommands are 'top', 'report' and 'annotate'.

> +
> +buildid.*::
> +	buildid.dir::
> +		Each executable or shared library built with each program is assigned
> +		a unique identification as build-id. The option means a path where
> +		build-id informations can be saved.
> +		The default of this option is /root/.debug

The default is $HOME/.debug

> +
> +annotate.*::
> +	There’re options which work with a ’annotate’ sub-command.
> +	This Options is in control of addresses, jump function, source code
> +	in lines of assembly code from a specific program. 
> +
> +	annotate.hide_src_code::
> +		If a program which is analyzed has source code of itself,
> +		this option let ‘annotate’ print a list of assembly code with the source code.
> +		For example, let’s see a part of a program. There’re four lines.
> +		If this option is ‘false’, they can be printed 
> +		without source code from a program as below.
> +
> +		│        push   %rbp
> +		│        mov    %rsp,%rbp
> +		│        sub    $0x10,%rsp
> +		│        mov    (%rdi),%rdx
> +		
> +		But if this option is ‘true’, source code of the part 
> +		can be also printed as below.
> + 
> +		│      struct rb_node *rb_next(const struct rb_node *node)
> +		│      {
> +		│        push   %rbp
> +		│        mov    %rsp,%rbp
> +		│        sub    $0x10,%rsp
> +		│              struct rb_node *parent;
> +		│
> +		│              if (RB_EMPTY_NODE(node))
> +		│        mov    (%rdi),%rdx
> +		│              return n;
> +
> +        annotate.use_offset::
> +		Basing on a first address of a loaded function, offset can be used.
> +		Instead of using original addresses of assembly code,
> +		addresses subtracted from a base address can be printed.
> +		Let’s illustrate a example. 
> +		If a base address is 0XFFFFFFFF81624d50 as below,
> +
> +		ffffffff81624d50 <load0>
> +
> +		a address on assembly code has a specific absolute address as below
> +
> +		ffffffff816250b8:│  mov    0x8(%r14),%rdi
> +
> +		but if use_offset is ’true’, a address subtracted from a base address is printed.
> +		The default is positive.
> +
> +		             368:│  mov    0x8(%r14),%rdi
> +
> +	annotate.jump_arrows::
> +		There’re jump instruction among assembly code.
> +		Depending on a boolean value of jump_arrows,
> +		arrows can be printed or not which represent 
> +		where do the instruction jump into as below.
> +
> +		│     ┌──jmp    1333
> +		│     │  xchg   %ax,%ax
> +		│1330:│  mov    %r15,%r10
> +		│1333:└─→cmp    %r15,%r14
> +
> +		If jump_arrow is ‘false’, the arrows isn’t printed as below.
> +
> +		│      ↓ jmp    1333
> +		│        xchg   %ax,%ax
> +		│1330:   mov    %r15,%r10
> +		│1333:   cmp    %r15,%r14
> +
> +        annotate.show_nr_jumps::
> +		Let’s see a part of assembly code.
> + 
> +		│1382:   movb   $0x1,-0x270(%rbp)
> +
> +		If use this, the number of branches branching to that address can be printed as below.
> +
> +		│1 1382:   movb   $0x1,-0x270(%rbp)
> +
> +help.*::
> +	help.format:: = man
> +		A format of manual page can be ‘man’, ‘info’, ‘web’ or ‘html’.
> +		’man’ is default.
> +	help.autocorrect:: = 0
> +		Automatically correct and execute mistyped commands after
> +		waiting for the given number of deciseconds (0.1 sec).
> +		When this option is 0 if execute a mistyped sub-command instead of ‘top’,
> +
> +		perf: 'ttop' is not a perf-command. See 'perf --help’.
> +
> +		If this option is more than 1, the output can be such as.
> +
> +		WARNING: You called a perf program named 'ttop', which does not exist.
> +		Continuing under the assumption that you meant 'with-kcore'
> +		in 0.1 seconds automatically...
> +		Usage: perf-with-kcore <perf sub-command> <perf.data directory> [<sub-command options> [ -- <workload>]]
> +       		<perf sub-command> can be record, script, report or inject		
> +		    or: perf-with-kcore fix_buildid_cache_permissions
> +
> +hist.*::
> +	hist.percentage::
> +		A value of 'percentage' can be 'relative' or 'absolute'

This option control a way to calcurate overhead of filtered entries -
that means the value of this option is effective only if there's a
filter (by comm, dso or symbol name).  Suppose a following example:

	Overhead  Symbols
	........  .......
	  33.33%  foo
	  33.33%  bar
	  33.33%  baz
	  
This is an original overhead and we'll filter out the first 'foo'
entry.  The value of 'relative' would increase the overhead of 'bar'
and 'baz' to 50.00% for each, while 'absolute' would show their
current overhead (33.33%).

> +
> +ui.*::
> +	ui.show-headers::
> +		There’re columns as header ‘Overhead’, ‘Children’, ‘Shared Object’, ‘Symbol’, ’self’.
> +		If this option is negative, they is hided.
> +
> +call-graph.*::
> +	When sub-commands ‘top’ and ‘report’ work with -g/—-children 
> +	there’re options in control of call-graph.
> +
> +	call-graph.record-mode::
> +		The record-mode can be ‘fp’ (frame pointer) and ‘dwarf’.
> +		If using 'Dwarf style', it requires dump-size has a value.

The value of 'dwarf' is effective only if perf detect needed library
(libunwind or a recent version of libdw).  Also it doesn't *require*
the dump-size option since it can use the default value of 8192 if
missing.


> +
> +	call-graph.dump-size::
> +		When using dwarf into record-mode this option should have a value.

The size of stack to dump in order to do post-unwinding.  Default is 8192 (byte).


> +
> +	call-graph.print-type::
> +		The print-types can be graph (graph absolute), flat, fractal (graph relative).

This option controls a way to show overhead for each callchain entry.
Suppose a following example.

 Overhead  Symbols
 ........  .......
   40.00%  foo
           |
	   --- foo
	       |
	       |--50.00%-- bar
	       |           main
	       |
	        --50.00%-- baz
	                   main

This output is a default format which is 'fractal'.  The 'foo' came
from 'bar' and 'baz' exactly half and half so 'fractal' shows 50.00%
for each (meaning that it assumes 100% total overhead of 'foo').

The 'graph' uses absolute overhead value of 'foo' as total so each of
'bar' and 'baz' callchain will have 20.00% of overhead.

I don't know what 'flat' should look like.. ;-P


> +
> +	call-graph.order::
> +		This option means the criterion of call-graph.
> +		A value of 'order' can be 'caller' or 'callee’.

This option controls print order of callchains.  The default is
'callee' which means callee is printed at top and then followed by its
caller and so on.  The 'caller' prints it in reverse order.


> +
> +	call-graph.sort-key::
> +			A value of 'sort-key' can be 'function' or 'address’.
> +			The default is ‘function’.

The callchains are merged if they contain same information.  The
sort-key option determines a way to compare the callchains.


> +
> +	call-graph.threshold::

When there're many callchains it'd print tons of lines.  So perf omits
small callchains under a certain overhead (threshold) and this option
control the threashold.  Default is 0.5 (%).


> +	call-graph.print-limit::

This is another way to control the number of callchains printed for a
single entry.  Default is 0 which means no limitation.


> +
> +report.*::
> +	report.percent-limit::
> +		If percent-limit is 70, the output which has percentages of 
> +		each overhead above 70% can be printed.

This one is mostly same as call-graph.threshold but works for
histogram entries.  Entries have overhead lower than this percentage
will not be printed.  Default is 0.


> +	report.children::
> +		The children means that functions called from another function.
> +		If the option is positive, accumulate callchain of children and show total overhead.

s/positive/true/


> +		For example, there’re three functions like below.
> +
> +		 void foo(void) {
> +		   /* do something */
> +		 }
> +
> +		 void bar(void) {
> +		   /* do something */
> +		   foo();
> +		 }
> +
> +		 int main(void) {
> +		   bar()
> +		   return 0;
> +		 }
> +
> +		Defaultly the output of sub-commands such as ’top’, ‘report’ and ‘annotate’
> +		depend on a sort of overhead into each functions as below.
> +	
> +		Overhead  Symbol
> +		........  .....................
> +		  60.00%  foo
> +		          |
> +		          --- foo
> +		              bar
> +		              main
> +		              __libc_start_main
> +
> +		  40.00%  bar
> +		          |
> +		          --- bar
> +		              main
> +		              __libc_start_main
> +
> +		But if this option is positive, the sort is changed into a sort of
> +		overhead into each children group of each function  reciting all functions 
> +		from a first parent function till a last child function like below.
> +		And it requires -g/--call-graph option enabled
> +
> +		Children      Self  Symbol
> +		........  ........  ....................
> +		 100.00%     0.00%  __libc_start_main
> +		          |
> +		          --- __libc_start_main
> +
> +		 100.00%     0.00%  main
> +		          |
> +		          --- main
> +		              __libc_start_main
> +
> +		 100.00%    40.00%  bar
> +		          |
> +		          --- bar
> +		              main
> +		              __libc_start_main
> +
> +		  60.00%    60.00%  foo
> +		          |
> +		          --- foo
> +		              bar
> +		              main
> +		              __libc_start_main
> +
> +top.*::
> +	top.children::
> +		This option means same as report.children.
> +		So it is positive, the output of ‘top’ is rearranged by each overhead into children group.

Ditto.  s/positive/true/

Thanks,
Namhyung


> +
> +SEE ALSO
> +--------
> +linkperf:perf[1]
> diff --git a/tools/perf/Documentation/perfconfig.example b/tools/perf/Documentation/perfconfig.example
> index 767ea24..86d0e0c 100644
> --- a/tools/perf/Documentation/perfconfig.example
> +++ b/tools/perf/Documentation/perfconfig.example
> @@ -1,29 +1,70 @@
>  [colors]
> -
> -	# These were the old defaults
> -	top = red, lightgray
> -	medium = green, lightgray
> -	normal = black, lightgray
> -	selected = lightgray, magenta
> -	code = blue, lightgray
> -	addr = magenta, lightgray
> +	# There are types of colors which are red,
> +	# green, default, black, blue,
> +	# white, magenta, lightgray
> +	# The default is like below
> +	top = red, default
> +	medium = green, default
> +	normal = lightgray, default
> +	selected = white, lightgray
> +	code = blue, default
> +	addr = magenta, default
> +	root = white, blue
>  
>  [tui]
> -
>  	# Defaults if linked with libslang
>  	report = on
>  	annotate = on
>  	top = on
>  
>  [buildid]
> -
>  	# Default, disable using /dev/null
>  	dir = /root/.debug
>  
>  [annotate]
> -
>  	# Defaults
>  	hide_src_code = false
>  	use_offset = true
>  	jump_arrows = true
>  	show_nr_jumps = false
> +
> +[gtk]
> +	report = off
> +	annotate = off
> +	#top = off
> +
> +[pager]
> +	# That a 'cmd' is true mean to use "pager or less"
> +	cmd = true
> +
> +[help]
> +	# Format can be man, info, web or html
> +	format = man
> +	autocorrect = 0
> +
> +[hist]
> +	# a value of 'percentage' can be 'relative' or 'absolute'
> +	percentage = absolute
> +
> +[ui]
> +	show-headers= true
> +
> +[call-graph]
> +	# fp (framepointer), dwarf
> +	record-mode = fp
> +
> +	# graph (graph absolute), flat, fractal (graph relative)
> +	print-type = fractal
> +
> +	# caller, callee
> +	order = caller
> +
> +	# function, address
> +	sort-key = function
> +
> +[report]
> +	percent-limit = 1
> +	children = false
> +
> +[top]
> +	children = true
> diff --git a/tools/perf/builtin-config.c b/tools/perf/builtin-config.c
> new file mode 100644
> index 0000000..cb4e72e
> --- /dev/null
> +++ b/tools/perf/builtin-config.c
> @@ -0,0 +1,56 @@
> +/*
> + * builtin-config.c
> + *
> + * Copyright (C) 2015, Taeung Song <treeze.taeung@...il.com>
> + *
> + */
> +#include "builtin.h"
> +
> +#include "perf.h"
> +
> +#include "util/cache.h"
> +#include "util/parse-options.h"
> +#include "util/util.h"
> +#include "util/debug.h"
> +
> +static struct {
> +	bool list_action;
> +} params;
> +
> +static int show_all_config(const char *key, const char *value,
> +			   void *cb __maybe_unused)
> +{
> +	if (value)
> +		printf("%s=%s\n", key, value);
> +	else
> +		printf("%s\n", key);
> +
> +	return 0;
> +}
> +
> +int cmd_config(int argc, const char **argv, const char *prefix __maybe_unused)
> +{
> +	int ret = 0;
> +	const char * const config_usage[] = {
> +		"perf config --list",
> +		NULL
> +	};
> +	const struct option options[] = {
> +		OPT_BOOLEAN('l', "list", &params.list_action, "list up current configurations"),
> +		OPT_END()
> +	};
> +
> +	argc = parse_options(argc, argv, options, config_usage,
> +			     PARSE_OPT_STOP_AT_NON_OPTION);
> +	if (argc > 0) {
> +		if (strcmp(argv[0], "-") == 0)
> +			pr_warning("  Error: '-' is not supported.\n");
> +
> +		usage_with_options(config_usage, options);
> +	}
> +
> +	if (params.list_action)
> +		ret = perf_config(show_all_config, NULL);
> +
> +	return ret;
> +}
> diff --git a/tools/perf/builtin.h b/tools/perf/builtin.h
> index 3688ad2..3f871b5 100644
> --- a/tools/perf/builtin.h
> +++ b/tools/perf/builtin.h
> @@ -17,6 +17,7 @@ extern int cmd_annotate(int argc, const char **argv, const char *prefix);
>  extern int cmd_bench(int argc, const char **argv, const char *prefix);
>  extern int cmd_buildid_cache(int argc, const char **argv, const char *prefix);
>  extern int cmd_buildid_list(int argc, const char **argv, const char *prefix);
> +extern int cmd_config(int argc, const char **argv, const char *prefix);
>  extern int cmd_diff(int argc, const char **argv, const char *prefix);
>  extern int cmd_evlist(int argc, const char **argv, const char *prefix);
>  extern int cmd_help(int argc, const char **argv, const char *prefix);
> diff --git a/tools/perf/command-list.txt b/tools/perf/command-list.txt
> index 00fcaf8..acc3ea7 100644
> --- a/tools/perf/command-list.txt
> +++ b/tools/perf/command-list.txt
> @@ -9,6 +9,7 @@ perf-buildid-cache		mainporcelain common
>  perf-buildid-list		mainporcelain common
>  perf-data			mainporcelain common
>  perf-diff			mainporcelain common
> +perf-config			mainporcelain common
>  perf-evlist			mainporcelain common
>  perf-inject			mainporcelain common
>  perf-kmem			mainporcelain common
> diff --git a/tools/perf/perf.c b/tools/perf/perf.c
> index b857fcb..604fa4a 100644
> --- a/tools/perf/perf.c
> +++ b/tools/perf/perf.c
> @@ -37,6 +37,7 @@ struct cmd_struct {
>  static struct cmd_struct commands[] = {
>  	{ "buildid-cache", cmd_buildid_cache, 0 },
>  	{ "buildid-list", cmd_buildid_list, 0 },
> +	{ "config",	cmd_config,	0 },
>  	{ "diff",	cmd_diff,	0 },
>  	{ "evlist",	cmd_evlist,	0 },
>  	{ "help",	cmd_help,	0 },
> -- 
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@...r.kernel.org
> 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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists