Perf - Revision history

Robert-schone-5513@tu-dresden.de at 13:06, 23 September 2019

2019-09-23T13:06:29Z

Robert-schone-5513@tu-dresden.de at 13:06, 23 September 2019

2019-09-23T13:06:17Z

Robert-schone-5513@tu-dresden.de: /* Overview and Installation */

2019-09-23T13:01:06Z

Overview and Installation

Robert-schone-5513@tu-dresden.de: /* Archiving of Scientific Data */

2019-09-23T13:00:27Z

Archiving of Scientific Data

Robert-schone-5513@tu-dresden.de at 12:59, 23 September 2019

2019-09-23T12:59:44Z

Robert-schone-5513@tu-dresden.de: /* Trace and Processing with perf script */

2019-09-23T12:50:24Z

Trace and Processing with perf script

Robert-schone-5513@tu-dresden.de: /* Measuring Events with perf stat */

2019-09-23T12:28:39Z

Measuring Events with perf stat

Robert-schone-5513@tu-dresden.de: /* Event-based Sampling with perf record and other Tools */

2019-09-23T12:28:12Z

Event-based Sampling with perf record and other Tools

Robert-schone-5513@tu-dresden.de: /* Event-based Sampling with perf record and other Tools */

2019-09-23T12:09:52Z

Event-based Sampling with perf record and other Tools

Robert-schone-5513@tu-dresden.de: /* Event-based Sampling with perf record */

2019-09-23T12:09:33Z

Event-based Sampling with perf record

@@ Line 6: / Line 6: @@
 To install Perf, use the <code>linux-tools-common</code> package on Debian based systems and <code>perf</code> on SuSE.
-''Some of the features might need special permissions to be granted to users.'' This can be done by tweaking the pseudo file <code>/proc/sys/kernel/perf_event_paranoid</code>. According to the perf help text (Linux 4.18) the contents of this file can have the following properties with the respective meanings.
+'''Some of the features might need special permissions to be granted to users.''' This can be done by tweaking the pseudo file <code>/proc/sys/kernel/perf_event_paranoid</code>. According to the perf help text (Linux 4.18) the contents of this file can have the following properties with the respective meanings.
 * <code> -1 </code>: Allow use of (almost) all events by all users. Ignore mlock limit after <code>perf_event_mlock_kb</code> without <code>CAP_IPC_LOCK</code>

@@ Line 6: / Line 6: @@
 To install Perf, use the <code>linux-tools-common</code> package on Debian based systems and <code>perf</code> on SuSE.
-Some of the features might need special permissions to be granted to users. This can be done by tweaking the pseudo file <code>/proc/sys/kernel/perf_event_paranoid</code>. According to the perf help text (Linux 4.18) the contents of this file can have the following properties with the respective meanings.
+''Some of the features might need special permissions to be granted to users.'' This can be done by tweaking the pseudo file <code>/proc/sys/kernel/perf_event_paranoid</code>. According to the perf help text (Linux 4.18) the contents of this file can have the following properties with the respective meanings.
 * <code> -1 </code>: Allow use of (almost) all events by all users. Ignore mlock limit after <code>perf_event_mlock_kb</code> without <code>CAP_IPC_LOCK</code>
@@ Line 38: / Line 38: @@
 === Raw Events ===
-You can specify hardware PMC events also by their actual ID. Refer to the processor manual to find the ID for the event that you want to monitor. Usually, the Umask is defined in Bits 8-15 and the event is specified in Bits 0-7. For the event `LD_BLOCKS.STORE_FORWARD` on 4th Generation Intel Core Processors, the umask and event are 0x02 and 0x03, respectively (Intel Manual 3, Table 19-7 [http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-system-programming-manual-325384.pdf] ). Hence, the raw event encoding would be <code>r302</code>.
+You can specify hardware PMC events also by their actual ID. Refer to the processor manual to find the ID for the event that you want to monitor. Usually, the Umask is defined in Bits 8-15 and the event is specified in Bits 0-7. For the event <code>LD_BLOCKS.STORE_FORWARD</code> on 4th Generation Intel Core Processors, the umask and event are 0x02 and 0x03, respectively (Intel Manual 3, Table 19-7 [http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-system-programming-manual-325384.pdf] ). Hence, the raw event encoding would be <code>r302</code>.
@@ Line 56: / Line 56: @@
 * <code>-e / --event=</code> specify the event(s) to be measured
 * <code>-x / --field-separator SEP</code> will print statistics CSV like, SEP will be used as separator.
-* <code>`-C / --cpu=<cpu-list></code> will measure the events on the list of given CPUS
+* <code>-C / --cpu=<cpu-list></code> will measure the events on the list of given CPUS
 * <code>-A / --no-aggr</code> Do not aggregate counts across all monitored CPUs
 * <code>-a / --all-cpus</code> Monitor all CPUs
@@ Line 89: / Line 89: @@
 === Recording with <code>perf record</code> ===
-When recording, the execution of processes is interrupted at intervals. The current state (PID, instruction pointer, time, ...) is taken and stored to the log file. As for `perf stat`, hardware threads (CPUs) or processes/threads can be monitored. Based on the log file, either a trace or profile can be shown or the single entries of the file can be processed using python or perl.
+When recording, the execution of processes is interrupted at intervals. The current state (PID, instruction pointer, time, ...) is taken and stored to the log file. As for <code>perf stat</code>, hardware threads (CPUs) or processes/threads can be monitored. Based on the log file, either a trace or profile can be shown or the single entries of the file can be processed using python or perl.
 '''Interpret with Caution!''' The interrupt interval is '''not necessarily equidistant in time'''! The default event <code>cycles</code> depends on processor idle states as much as frequency. Other events that can be used as a base for the interrupt are not equidistant either (e.g., instructions, cache misses). Moreover, the captured instruction pointer can have a small offset different from the actual instruction.
@@ Line 96: / Line 96: @@
 * <code>-c / --count=</code> Event period to sample. Higher -> more pertubation, lower -> less samples
-* <code>-e / --events=</code> as for `perf stat`, you can specify events here. For example, if you are interested in functions where cache misses happen, use `-e cache-misses`
+* <code>-e / --events=</code> as for <code>perf stat</code>, you can specify events here. For example, if you are interested in functions where cache misses happen, use <code>-e cache-misses</code>
-* <code>-g / --callpath</code> add call path profiling. If available, `perf` will try to not only sample the current function, but also the callpath. This works better on x86 if the framepointer is available. Please compile your code with <code>-fno-omit-framepointer</code>. If you do not do so, perf will try other means, which can also influence the monitoring overhead.
+* <code>-g / --callpath</code> add call path profiling. If available, <code>perf</code> will try to not only sample the current function, but also the callpath. This works better on x86 if the framepointer is available. Please compile your code with <code>-fno-omit-framepointer</code>. If you do not do so, perf will try other means, which can also influence the monitoring overhead.
 * <code>--user-regs</code> also capture user registers
 * <code>--switch-events</code> also capture switch events (for statistics on when exactly processes/threads are switched by the OS)

@@ Line 6: / Line 6: @@
 To install Perf, use the <code>linux-tools-common</code> package on Debian based systems and <code>perf</code> on SuSE.
-Some of the features might need special permissions to be granted to users. This can be done by tweaking the pseudo file `/proc/sys/kernel/perf_event_paranoid`. According to the perf help text (Linux 4.18) the contents of this file can have the following properties with the respective meanings.
+Some of the features might need special permissions to be granted to users. This can be done by tweaking the pseudo file <code>/proc/sys/kernel/perf_event_paranoid</code>. According to the perf help text (Linux 4.18) the contents of this file can have the following properties with the respective meanings.
 * <code> -1 </code>: Allow use of (almost) all events by all users. Ignore mlock limit after <code>perf_event_mlock_kb</code> without <code>CAP_IPC_LOCK</code>

@@ Line 129: / Line 129: @@
 === Archiving of Scientific Data ===
-You will not be able to report or script a log file on a different computer. Even on the system-under-test, the shared objects will change (recompilation, updates) and the information within the recorded log-files will be incomplete, if not useless. Use the `perf archive` function [https://github.com/torvalds/linux/blob/master/tools/perf/perf-archive.sh], to create an archive that contains all information on the used shared objects. These archives can become quite large. Still the data can now be processed on all other systems.
+You will not be able to report or script a log file on a different computer. Even on the system-under-test, the shared objects will change (recompilation, updates) and the information within the recorded log-files will be incomplete, if not useless. Use the <code>perf archive</code> function [https://github.com/torvalds/linux/blob/master/tools/perf/perf-archive.sh], to create an archive that contains all information on the used shared objects. These archives can become quite large. Still the data can now be processed on all other systems.
 == Sources ==

@@ Line 43: / Line 43: @@
 === Tracepoint Events ===
 In addition to increasing counters, the kernel is instrumented, whioch provides you with the possibility to grap any specified event within the kernel. Most of these also provide access to some arguments, which are highly event-specific. For a definition of these events, check your <code>tracefs</code> mountpoint, usually under <code>/sys/kernel/debug/tracing</code>.
 == Measuring Events with <code>perf stat</code> ==
@@ Line 129: / Line 131: @@
 You will not be able to report or script a log file on a different computer. Even on the system-under-test, the shared objects will change (recompilation, updates) and the information within the recorded log-files will be incomplete, if not useless. Use the `perf archive` function [https://github.com/torvalds/linux/blob/master/tools/perf/perf-archive.sh], to create an archive that contains all information on the used shared objects. These archives can become quite large. Still the data can now be processed on all other systems.
-== Function Top ==
+== Sources ==

← Older revision		Revision as of 12:50, 23 September 2019
Line 118:		Line 118:
	=== Trace and Processing with <code>perf script</code> ===		=== Trace and Processing with <code>perf script</code> ===

		+	In addition to watching the profile, you can also process it with a script. By default, all entries of the log file will be printed. And you can use command line tools to process them further. However, you usually want to make use of the perl or python (depending on your perf installation) interface to process the single samples.

		+	==== Example ====
		+
		+	* <code>perf script -g python </code> generate the stub <code>perf-script.py</code>for processing the log file in Python
		+	* <code>perf script report perf-script.py</code> run <code>perf-script.py</code> on the default log file (<code>perf.data</code>)

	=== Archiving of Scientific Data ===		=== Archiving of Scientific Data ===

← Older revision		Revision as of 12:28, 23 September 2019
Line 47:		Line 47:

	Use the <code>perf stat</code> command to measure available events. This will set-up the hardware and software counters and either collect the information for the applied process or the CPU(s) (meaning hardware threads) that are requested. <code>perf stat</code> provides various command line arguments (see perf-stat man page [https://linux.die.net/man/1/perf-stat] ). Some of the important ones are:		Use the <code>perf stat</code> command to measure available events. This will set-up the hardware and software counters and either collect the information for the applied process or the CPU(s) (meaning hardware threads) that are requested. <code>perf stat</code> provides various command line arguments (see perf-stat man page [https://linux.die.net/man/1/perf-stat] ). Some of the important ones are:
		+
		+	=== Selected Argments ===

	* <code>-d / --detailed</code> collects more events, can be provided multiple times		* <code>-d / --detailed</code> collects more events, can be provided multiple times

@@ Line 83: / Line 83: @@
 '''Caution with File Size''' The sample file sizes can get quite large. This should not be done on a slow file system.
-=== Recording ===
+=== Recording with <code>perf record</code> ===
 When recording, the execution of processes is interrupted at intervals. The current state (PID, instruction pointer, time, ...) is taken and stored to the log file. As for `perf stat`, hardware threads (CPUs) or processes/threads can be monitored. Based on the log file, either a trace or profile can be shown or the single entries of the file can be processed using python or perl.
 '''Interpret with Caution!''' The interrupt interval is '''not necessarily equidistant in time'''! The default event <code>cycles</code> depends on processor idle states as much as frequency. Other events that can be used as a base for the interrupt are not equidistant either (e.g., instructions, cache misses). Moreover, the captured instruction pointer can have a small offset different from the actual instruction.
 * <code>-c / --count=</code> Event period to sample. Higher -> more pertubation, lower -> less samples
@@ Line 107: / Line 109: @@
-=== Profile ===
+=== Profile with <code>perf report</code> ===
@@ Line 113: / Line 121: @@
 You will not be able to report or script a log file on a different computer. Even on the system-under-test, the shared objects will change (recompilation, updates) and the information within the recorded log-files will be incomplete, if not useless. Use the `perf archive` function [https://github.com/torvalds/linux/blob/master/tools/perf/perf-archive.sh], to create an archive that contains all information on the used shared objects. These archives can become quite large. Still the data can now be processed on all other systems.
 == Function Top ==

@@ Line 81: / Line 81: @@
 With <code>perf record</code>, you can set-up an event based sampling. The samples will be written to a log file, which is typically later processed with <code>perf report</code> to create a profile.
-!!! Caution with File Size !!! The sample file sizes can get quite large. This should not be done on a slow file system.
+'''Caution with File Size''' The sample file sizes can get quite large. This should not be done on a slow file system.
 === Recording ===

@@ Line 77: / Line 77: @@
 When monitoring a process, all child processes and threads will also be monitored. This can be avoided by providing the <code>-i, --no-inherit</code> flag.
-== Event-based Sampling with <code>perf record</code> ==
+== Event-based Sampling with <code>perf record</code> and other Tools ==
 With <code>perf record</code>, you can set-up an event based sampling. The samples will be written to a log file, which is typically later processed with <code>perf report</code> to create a profile.
-(TODO)
 === Recording ===
 === Profile ===
 === Trace ===
 == Function Top ==