Merge tag 'docs-4.18' of git://git.lwn.net/linux
Pull documentation updates from Jonathan Corbet:
"There's been a fair amount of work in the docs tree this time around,
including:
- Extensive RST conversions and organizational work in the
memory-management docs thanks to Mike Rapoport.
- An update of Documentation/features from Andrea Parri and a script
to keep it updated.
- Various LICENSES updates from Thomas, along with a script to check
SPDX tags.
- Work to fix dangling references to documentation files; this
involved a fair number of one-liner comment changes outside of
Documentation/
... and the usual list of documentation improvements, typo fixes, etc"
* tag 'docs-4.18' of git://git.lwn.net/linux: (103 commits)
Documentation: document hung_task_panic kernel parameter
docs/admin-guide/mm: add high level concepts overview
docs/vm: move ksm and transhuge from "user" to "internals" section.
docs: Use the kerneldoc comments for memalloc_no*()
doc: document scope NOFS, NOIO APIs
docs: update kernel versions and dates in tables
docs/vm: transhuge: split userspace bits to admin-guide/mm/transhuge
docs/vm: transhuge: minor updates
docs/vm: transhuge: change sections order
Documentation: arm: clean up Marvell Berlin family info
Documentation: gpio: driver: Fix a typo and some odd grammar
docs: ranoops.rst: fix location of ramoops.txt
scripts/documentation-file-ref-check: rewrite it in perl with auto-fix mode
docs: uio-howto.rst: use a code block to solve a warning
mm, THP, doc: Add document for thp_swpout/thp_swpout_fallback
w1: w1_io.c: fix a kernel-doc warning
Documentation/process/posting: wrap text at 80 cols
docs: admin-guide: add cgroup-v2 documentation
Revert "Documentation/features/vm: Remove arch support status file for 'pte_special'"
Documentation: refcount-vs-atomic: Update reference to LKMM doc.
...
此提交包含在：
Linus Torvalds
@@ -187,13 +187,19 @@ that can be performed on them (see "struct coresight_ops"). The
|
||||
specific to that component only. "Implementation defined" customisations are
|
||||
expected to be accessed and controlled using those entries.
|
||||
|
||||
Last but not least, "struct module *owner" is expected to be set to reflect
|
||||
the information carried in "THIS_MODULE".
|
||||
|
||||
How to use the tracer modules
|
||||
-----------------------------
|
||||
|
||||
Before trace collection can start, a coresight sink needs to be identify.
|
||||
There are two ways to use the Coresight framework: 1) using the perf cmd line
|
||||
tools and 2) interacting directly with the Coresight devices using the sysFS
|
||||
interface. Preference is given to the former as using the sysFS interface
|
||||
requires a deep understanding of the Coresight HW. The following sections
|
||||
provide details on using both methods.
|
||||
|
||||
1) Using the sysFS interface:
|
||||
|
||||
Before trace collection can start, a coresight sink needs to be identified.
|
||||
There is no limit on the amount of sinks (nor sources) that can be enabled at
|
||||
any given moment. As a generic operation, all device pertaining to the sink
|
||||
class will have an "active" entry in sysfs:
|
||||
@@ -298,42 +304,48 @@ Instruction 13570831 0x8026B584 E28DD00C false ADD
|
||||
Instruction 0 0x8026B588 E8BD8000 true LDM sp!,{pc}
|
||||
Timestamp Timestamp: 17107041535
|
||||
|
||||
How to use the STM module
|
||||
-------------------------
|
||||
2) Using perf framework:
|
||||
|
||||
Using the System Trace Macrocell module is the same as the tracers - the only
|
||||
difference is that clients are driving the trace capture rather
|
||||
than the program flow through the code.
|
||||
Coresight tracers are represented using the Perf framework's Performance
|
||||
Monitoring Unit (PMU) abstraction. As such the perf framework takes charge of
|
||||
controlling when tracing gets enabled based on when the process of interest is
|
||||
scheduled. When configured in a system, Coresight PMUs will be listed when
|
||||
queried by the perf command line tool:
|
||||
|
||||
As with any other CoreSight component, specifics about the STM tracer can be
|
||||
found in sysfs with more information on each entry being found in [1]:
|
||||
linaro@linaro-nano:~$ ./perf list pmu
|
||||
|
||||
root@genericarmv8:~# ls /sys/bus/coresight/devices/20100000.stm
|
||||
enable_source hwevent_select port_enable subsystem uevent
|
||||
hwevent_enable mgmt port_select traceid
|
||||
root@genericarmv8:~#
|
||||
List of pre-defined events (to be used in -e):
|
||||
|
||||
Like any other source a sink needs to be identified and the STM enabled before
|
||||
being used:
|
||||
cs_etm// [Kernel PMU event]
|
||||
|
||||
root@genericarmv8:~# echo 1 > /sys/bus/coresight/devices/20010000.etf/enable_sink
|
||||
root@genericarmv8:~# echo 1 > /sys/bus/coresight/devices/20100000.stm/enable_source
|
||||
linaro@linaro-nano:~$
|
||||
|
||||
From there user space applications can request and use channels using the devfs
|
||||
interface provided for that purpose by the generic STM API:
|
||||
Regardless of the number of tracers available in a system (usually equal to the
|
||||
amount of processor cores), the "cs_etm" PMU will be listed only once.
|
||||
|
||||
root@genericarmv8:~# ls -l /dev/20100000.stm
|
||||
crw------- 1 root root 10, 61 Jan 3 18:11 /dev/20100000.stm
|
||||
root@genericarmv8:~#
|
||||
A Coresight PMU works the same way as any other PMU, i.e the name of the PMU is
|
||||
listed along with configuration options within forward slashes '/'. Since a
|
||||
Coresight system will typically have more than one sink, the name of the sink to
|
||||
work with needs to be specified as an event option. Names for sink to choose
|
||||
from are listed in sysFS under ($SYSFS)/bus/coresight/devices:
|
||||
|
||||
Details on how to use the generic STM API can be found here [2].
|
||||
root@linaro-nano:~# ls /sys/bus/coresight/devices/
|
||||
20010000.etf 20040000.funnel 20100000.stm 22040000.etm
|
||||
22140000.etm 230c0000.funnel 23240000.etm 20030000.tpiu
|
||||
20070000.etr 20120000.replicator 220c0000.funnel
|
||||
23040000.etm 23140000.etm 23340000.etm
|
||||
|
||||
[1]. Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
|
||||
[2]. Documentation/trace/stm.txt
|
||||
root@linaro-nano:~# perf record -e cs_etm/@20070000.etr/u --per-thread program
|
||||
|
||||
The syntax within the forward slashes '/' is important. The '@' character
|
||||
tells the parser that a sink is about to be specified and that this is the sink
|
||||
to use for the trace session.
|
||||
|
||||
Using perf tools
|
||||
----------------
|
||||
More information on the above and other example on how to use Coresight with
|
||||
the perf tools can be found in the "HOWTO.md" file of the openCSD gitHub
|
||||
repository [3].
|
||||
|
||||
2.1) AutoFDO analysis using the perf tools:
|
||||
|
||||
perf can be used to record and analyze trace of programs.
|
||||
|
||||
@@ -381,3 +393,38 @@ sort example is from the AutoFDO tutorial (https://gcc.gnu.org/wiki/AutoFDO/Tuto
|
||||
$ taskset -c 2 ./sort_autofdo
|
||||
Bubble sorting array of 30000 elements
|
||||
5806 ms
|
||||
|
||||
|
||||
How to use the STM module
|
||||
-------------------------
|
||||
|
||||
Using the System Trace Macrocell module is the same as the tracers - the only
|
||||
difference is that clients are driving the trace capture rather
|
||||
than the program flow through the code.
|
||||
|
||||
As with any other CoreSight component, specifics about the STM tracer can be
|
||||
found in sysfs with more information on each entry being found in [1]:
|
||||
|
||||
root@genericarmv8:~# ls /sys/bus/coresight/devices/20100000.stm
|
||||
enable_source hwevent_select port_enable subsystem uevent
|
||||
hwevent_enable mgmt port_select traceid
|
||||
root@genericarmv8:~#
|
||||
|
||||
Like any other source a sink needs to be identified and the STM enabled before
|
||||
being used:
|
||||
|
||||
root@genericarmv8:~# echo 1 > /sys/bus/coresight/devices/20010000.etf/enable_sink
|
||||
root@genericarmv8:~# echo 1 > /sys/bus/coresight/devices/20100000.stm/enable_source
|
||||
|
||||
From there user space applications can request and use channels using the devfs
|
||||
interface provided for that purpose by the generic STM API:
|
||||
|
||||
root@genericarmv8:~# ls -l /dev/20100000.stm
|
||||
crw------- 1 root root 10, 61 Jan 3 18:11 /dev/20100000.stm
|
||||
root@genericarmv8:~#
|
||||
|
||||
Details on how to use the generic STM API can be found here [2].
|
||||
|
||||
[1]. Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
|
||||
[2]. Documentation/trace/stm.txt
|
||||
[3]. https://github.com/Linaro/perf-opencsd
|
||||
|
||||
@@ -12,7 +12,7 @@ Written for: 4.14
|
||||
Introduction
|
||||
============
|
||||
|
||||
The ftrace infrastructure was originially created to attach callbacks to the
|
||||
The ftrace infrastructure was originally created to attach callbacks to the
|
||||
beginning of functions in order to record and trace the flow of the kernel.
|
||||
But callbacks to the start of a function can have other use cases. Either
|
||||
for live kernel patching, or for security monitoring. This document describes
|
||||
@@ -30,7 +30,7 @@ The ftrace context
|
||||
This requires extra care to what can be done inside a callback. A callback
|
||||
can be called outside the protective scope of RCU.
|
||||
|
||||
The ftrace infrastructure has some protections agains recursions and RCU
|
||||
The ftrace infrastructure has some protections against recursions and RCU
|
||||
but one must still be very careful how they use the callbacks.
|
||||
|
||||
|
||||
|
||||
@@ -224,6 +224,8 @@ of ftrace. Here is a list of some of the key files:
|
||||
has a side effect of enabling or disabling specific functions
|
||||
to be traced. Echoing names of functions into this file
|
||||
will limit the trace to only those functions.
|
||||
This influences the tracers "function" and "function_graph"
|
||||
and thus also function profiling (see "function_profile_enabled").
|
||||
|
||||
The functions listed in "available_filter_functions" are what
|
||||
can be written into this file.
|
||||
@@ -265,6 +267,8 @@ of ftrace. Here is a list of some of the key files:
|
||||
Functions listed in this file will cause the function graph
|
||||
tracer to only trace these functions and the functions that
|
||||
they call. (See the section "dynamic ftrace" for more details).
|
||||
Note, set_ftrace_filter and set_ftrace_notrace still affects
|
||||
what functions are being traced.
|
||||
|
||||
set_graph_notrace:
|
||||
|
||||
@@ -277,7 +281,8 @@ of ftrace. Here is a list of some of the key files:
|
||||
|
||||
This lists the functions that ftrace has processed and can trace.
|
||||
These are the function names that you can pass to
|
||||
"set_ftrace_filter" or "set_ftrace_notrace".
|
||||
"set_ftrace_filter", "set_ftrace_notrace",
|
||||
"set_graph_function", or "set_graph_notrace".
|
||||
(See the section "dynamic ftrace" below for more details.)
|
||||
|
||||
dyn_ftrace_total_info:
|
||||
|
||||
新增問題並參考
封鎖使用者