tools/perf/Documentation/perf-config.txt

perf-config(1)
==============

NAME
----
perf-config - Get and set variables in a configuration file.

SYNOPSIS
--------
[verse]
'perf config' -l | --list

DESCRIPTION
-----------
You can manage variables in a configuration file with this command.

OPTIONS
-------

-l::
--list::
	Show current config variables, name and value, for all sections.

CONFIGURATION FILE
------------------

The perf configuration file contains many variables to change various
aspects of each of its tools, including output, disk usage, etc.
The '$HOME/.perfconfig' file is used to store a per-user configuration.
The file '$(sysconfdir)/perfconfig' can be used to
store a system-wide default configuration.

Syntax
~~~~~~

The file consist of sections. A section starts with its name
surrounded by square brackets and continues till the next section
begins. Each variable must be in a section, and have the form
'name = value', for example:

	[section]
		name1 = value1
		name2 = value2

Section names are case sensitive and can contain any characters except
newline (double quote `"` and backslash have to be escaped as `\"` and `\\`,
respectively). Section headers can't span multiple lines.

Example
~~~~~~~

Given a $HOME/.perfconfig like this:

#
# This is the config file, and
# a '#' and ';' character indicates a comment
#

	[colors]
		# Color variables
		top = red, default
		medium = green, default
		normal = lightgray, default
		selected = white, lightgray
		jump_arrows = 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 = ~/.debug

	[annotate]
		# Defaults
		hide_src_code = false
		use_offset = true
		jump_arrows = true
		show_nr_jumps = false

	[help]
		# Format can be man, info, web or html
		format = man
		autocorrect = 0

	[ui]
		show-headers = true

	[call-graph]
		# fp (framepointer), dwarf
		record-mode = fp
		print-type = graph
		order = caller
		sort-key = function

Variables
~~~~~~~~~

colors.*::
	The variables for customizing the colors used in the output for the
	'report', 'top' and 'annotate' in the TUI. They should specify the
	foreground and background colors, separated by a comma, for example:

		medium = green, lightgray

	If you want to use the color configured for you terminal, just leave it
	as 'default', for example:

		medium = default, lightgray

	Available colors:
	red, yellow, green, cyan, gray, black, blue,
	white, default, magenta, lightgray

	colors.top::
		'top' means a overhead percentage which is more than 5%.
		And values of this variable specify percentage colors.
		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 the rest of overhead percentages
		except 'top', 'medium', 'selected'.
		Default values are 'lightgray' and 'default'.
	colors.selected::
		This selects the colors for the current entry in a list of entries
		from sub-commands (top, report, annotate).
		Default values are 'black' and 'lightgray'.
	colors.jump_arrows::
		Colors for jump arrows on assembly code listings
		such as 'jns', 'jmp', 'jane', etc.
		Default values are 'blue', 'default'.
	colors.addr::
		This selects colors for addresses from 'annotate'.
		Default values are 'magenta', 'default'.
	colors.root::
		Colors for headers in the output of a sub-commands (top, report).
		Default values are 'white', 'blue'.

tui.*, gtk.*::
	Subcommands that can be configured here are 'top', 'report' and 'annotate'.
	These values are booleans, for example:

	[tui]
		top = true

	will make the TUI be the default for the 'top' subcommand. Those will be
	available if the required libs were detected at tool build time.

buildid.*::
	buildid.dir::
		Each executable and shared library in modern distributions comes with a
		content based identifier that, if available, will be inserted in a
		'perf.data' file header to, at analysis time find what is needed to do
		symbol resolution, code annotation, etc.

		The recording tools also stores a hard link or copy in a per-user
		directory, $HOME/.debug/, of binaries, shared libraries, /proc/kallsyms
		and /proc/kcore files to be used at analysis time.

		The buildid.dir variable can be used to either change this directory
		cache location, or to disable it altogether. If you want to disable it,
		set buildid.dir to /dev/null. The default is $HOME/.debug

SEE ALSO
--------
linkperf:perf[1]