AcoSail/kernel_optimize_test
8
0
Fork 0
forked from luck/tmp_suning_uos_patched
Code Pull Requests Activity

libperf: Fix man page typos

Browse Source 
Fix various typos and inconsistent capitalization of CPU in the libperf
man pages.

Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lore.kernel.org/lkml/20200807193241.3904545-1-robh@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
This commit is contained in:
Rob Herring 2020-08-07 13:32:41 -06:00 committed by Arnaldo Carvalho de Melo
parent 194cb6b50f
commit ce746d43a1
3 changed files with 17 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
tools/lib/perf/Documentation/libperf-counting.txt
View File

@ -7,13 +7,13 @@ libperf-counting - counting interface
DESCRIPTION
-----------
The counting interface provides API to meassure and get count for specific perf events.
The counting interface provides API to measure and get count for specific perf events.
The following test tries to explain count on `counting.c` example.
It is by no means complete guide to counting, but shows libperf basic API for counting.
The `counting.c` comes with libbperf package and can be compiled and run like:
The `counting.c` comes with libperf package and can be compiled and run like:
[source,bash]
--
@ -26,7 +26,8 @@ count 176242, enabled 176242, run 176242
It requires root access, because of the `PERF_COUNT_SW_CPU_CLOCK` event,
which is available only for root.
The `counting.c` example monitors two events on the current process and displays their count, in a nutshel it:
The `counting.c` example monitors two events on the current process and displays
their count, in a nutshell it:
* creates events
* adds them to the event list
@ -152,7 +153,7 @@ Configure event list with the thread map and open events:
--
Both events are created as disabled (note the `disabled = 1` assignment above),
so we need to enable the whole list explicitely (both events).
so we need to enable the whole list explicitly (both events).
From this moment events are counting and we can do our workload.
@ -167,7 +168,8 @@ When we are done we disable the events list.
79 perf_evlist__disable(evlist);
--
Now we need to get the counts from events, following code iterates throught the events list and read counts:
Now we need to get the counts from events, following code iterates through the
events list and read counts:
[source,c]
--
@ -178,7 +180,7 @@ Now we need to get the counts from events, following code iterates throught the
85 }
--
And finaly cleanup.
And finally cleanup.
We close the whole events list (both events) and remove it together with the threads map:

13
tools/lib/perf/Documentation/libperf-sampling.txt
View File

@ -8,13 +8,13 @@ libperf-sampling - sampling interface
DESCRIPTION
-----------
The sampling interface provides API to meassure and get count for specific perf events.
The sampling interface provides API to measure and get count for specific perf events.
The following test tries to explain count on `sampling.c` example.
It is by no means complete guide to sampling, but shows libperf basic API for sampling.
The `sampling.c` comes with libbperf package and can be compiled and run like:
The `sampling.c` comes with libperf package and can be compiled and run like:
[source,bash]
--
@ -33,7 +33,8 @@ cpu 0, pid 4465, tid 4470, ip 7f84fe0ebebf, period 176
It requires root access, because it uses hardware cycles event.
The `sampling.c` example profiles/samples all CPUs with hardware cycles, in a nutshel it:
The `sampling.c` example profiles/samples all CPUs with hardware cycles, in a
nutshell it:
- creates events
- adds them to the event list
@ -90,7 +91,7 @@ Once the setup is complete we start by defining cycles event using the `struct p
36 };
--
Next step is to prepare cpus map.
Next step is to prepare CPUs map.
In this case we will monitor all the available CPUs:
@ -152,7 +153,7 @@ Once the events list is open, we can create memory maps AKA perf ring buffers:
--
The event is created as disabled (note the `disabled = 1` assignment above),
so we need to enable the events list explicitely.
so we need to enable the events list explicitly.
From this moment the cycles event is sampling.
@ -212,7 +213,7 @@ Each sample needs to get parsed:
106 cpu, pid, tid, ip, period);
--
And finaly cleanup.
And finally cleanup.
We close the whole events list (both events) and remove it together with the threads map:

4
tools/lib/perf/Documentation/libperf.txt
View File

@ -29,7 +29,7 @@ SYNOPSIS
void libperf_init(libperf_print_fn_t fn);
--
*API to handle cpu maps:*
*API to handle CPU maps:*
[source,c]
--
@ -217,7 +217,7 @@ Following objects are key to the libperf interface:
[horizontal]
struct perf_cpu_map:: Provides a cpu list abstraction.
struct perf_cpu_map:: Provides a CPU list abstraction.
struct perf_thread_map:: Provides a thread list abstraction.