16c00db4bb
Pull AFS fixes from David Howells: "Here's a set of patches that fix a number of bugs in the in-kernel AFS client, including: - Fix directory locking to not use individual page locks for directory reading/scanning but rather to use a semaphore on the afs_vnode struct as the directory contents must be read in a single blob and data from different reads must not be mixed as the entire contents may be shuffled about between reads. - Fix address list parsing to handle port specifiers correctly. - Only give up callback records on a server if we actually talked to that server (we might not be able to access a server). - Fix some callback handling bugs, including refcounting, whole-volume callbacks and when callbacks actually get broken in response to a CB.CallBack op. - Fix some server/address rotation bugs, including giving up if we can't probe a server; giving up if a server says it doesn't have a volume, but there are more servers to try. - Fix the decoding of fetched statuses to be OpenAFS compatible. - Fix the handling of server lookups in Cache Manager ops (such as CB.InitCallBackState3) to use a UUID if possible and to handle no server being found. - Fix a bug in server lookup where not all addresses are compared. - Fix the non-encryption of calls that prevents some servers from being accessed (this also requires an AF_RXRPC patch that has already gone in through the net tree). There's also a patch that adds tracepoints to log Cache Manager ops that don't find a matching server, either by UUID or by address" * tag 'afs-fixes-20180514' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs: afs: Fix the non-encryption of calls afs: Fix CB.CallBack handling afs: Fix whole-volume callback handling afs: Fix afs_find_server search loop afs: Fix the handling of an unfound server in CM operations afs: Add a tracepoint to record callbacks from unlisted servers afs: Fix the handling of CB.InitCallBackState3 to find the server by UUID afs: Fix VNOVOL handling in address rotation afs: Fix AFSFetchStatus decoder to provide OpenAFS compatibility afs: Fix server rotation's handling of fileserver probe failure afs: Fix refcounting in callback registration afs: Fix giving up callbacks on server destruction afs: Fix address list parsing afs: Fix directory page locking
152 lines
4.7 KiB
Text
152 lines
4.7 KiB
Text
|
|
The contents of this directory allow users to specify PMU events in their
|
|
CPUs by their symbolic names rather than raw event codes (see example below).
|
|
|
|
The main program in this directory, is the 'jevents', which is built and
|
|
executed _BEFORE_ the perf binary itself is built.
|
|
|
|
The 'jevents' program tries to locate and process JSON files in the directory
|
|
tree tools/perf/pmu-events/arch/foo.
|
|
|
|
- Regular files with '.json' extension in the name are assumed to be
|
|
JSON files, each of which describes a set of PMU events.
|
|
|
|
- The CSV file that maps a specific CPU to its set of PMU events is to
|
|
be named 'mapfile.csv' (see below for mapfile format).
|
|
|
|
- Directories are traversed, but all other files are ignored.
|
|
|
|
- To reduce JSON event duplication per architecture, platform JSONs may
|
|
use "ArchStdEvent" keyword to dereference an "Architecture standard
|
|
events", defined in architecture standard JSONs.
|
|
Architecture standard JSONs must be located in the architecture root
|
|
folder. Matching is based on the "EventName" field.
|
|
|
|
The PMU events supported by a CPU model are expected to grouped into topics
|
|
such as Pipelining, Cache, Memory, Floating-point etc. All events for a topic
|
|
should be placed in a separate JSON file - where the file name identifies
|
|
the topic. Eg: "Floating-point.json".
|
|
|
|
All the topic JSON files for a CPU model/family should be in a separate
|
|
sub directory. Thus for the Silvermont X86 CPU:
|
|
|
|
$ ls tools/perf/pmu-events/arch/x86/Silvermont_core
|
|
Cache.json Memory.json Virtual-Memory.json
|
|
Frontend.json Pipeline.json
|
|
|
|
The JSONs folder for a CPU model/family may be placed in the root arch
|
|
folder, or may be placed in a vendor sub-folder under the arch folder
|
|
for instances where the arch and vendor are not the same.
|
|
|
|
Using the JSON files and the mapfile, 'jevents' generates the C source file,
|
|
'pmu-events.c', which encodes the two sets of tables:
|
|
|
|
- Set of 'PMU events tables' for all known CPUs in the architecture,
|
|
(one table like the following, per JSON file; table name 'pme_power8'
|
|
is derived from JSON file name, 'power8.json').
|
|
|
|
struct pmu_event pme_power8[] = {
|
|
|
|
...
|
|
|
|
{
|
|
.name = "pm_1plus_ppc_cmpl",
|
|
.event = "event=0x100f2",
|
|
.desc = "1 or more ppc insts finished,",
|
|
},
|
|
|
|
...
|
|
}
|
|
|
|
- A 'mapping table' that maps each CPU of the architecture, to its
|
|
'PMU events table'
|
|
|
|
struct pmu_events_map pmu_events_map[] = {
|
|
{
|
|
.cpuid = "004b0000",
|
|
.version = "1",
|
|
.type = "core",
|
|
.table = pme_power8
|
|
},
|
|
...
|
|
|
|
};
|
|
|
|
After the 'pmu-events.c' is generated, it is compiled and the resulting
|
|
'pmu-events.o' is added to 'libperf.a' which is then used to build perf.
|
|
|
|
NOTES:
|
|
1. Several CPUs can support same set of events and hence use a common
|
|
JSON file. Hence several entries in the pmu_events_map[] could map
|
|
to a single 'PMU events table'.
|
|
|
|
2. The 'pmu-events.h' has an extern declaration for the mapping table
|
|
and the generated 'pmu-events.c' defines this table.
|
|
|
|
3. _All_ known CPU tables for architecture are included in the perf
|
|
binary.
|
|
|
|
At run time, perf determines the actual CPU it is running on, finds the
|
|
matching events table and builds aliases for those events. This allows
|
|
users to specify events by their name:
|
|
|
|
$ perf stat -e pm_1plus_ppc_cmpl sleep 1
|
|
|
|
where 'pm_1plus_ppc_cmpl' is a Power8 PMU event.
|
|
|
|
However some errors in processing may cause the perf build to fail.
|
|
|
|
Mapfile format
|
|
===============
|
|
|
|
The mapfile enables multiple CPU models to share a single set of PMU events.
|
|
It is required even if such mapping is 1:1.
|
|
|
|
The mapfile.csv format is expected to be:
|
|
|
|
Header line
|
|
CPUID,Version,Dir/path/name,Type
|
|
|
|
where:
|
|
|
|
Comma:
|
|
is the required field delimiter (i.e other fields cannot
|
|
have commas within them).
|
|
|
|
Comments:
|
|
Lines in which the first character is either '\n' or '#'
|
|
are ignored.
|
|
|
|
Header line
|
|
The header line is the first line in the file, which is
|
|
always _IGNORED_. It can empty.
|
|
|
|
CPUID:
|
|
CPUID is an arch-specific char string, that can be used
|
|
to identify CPU (and associate it with a set of PMU events
|
|
it supports). Multiple CPUIDS can point to the same
|
|
File/path/name.json.
|
|
|
|
Example:
|
|
CPUID == 'GenuineIntel-6-2E' (on x86).
|
|
CPUID == '004b0100' (PVR value in Powerpc)
|
|
Version:
|
|
is the Version of the mapfile.
|
|
|
|
Dir/path/name:
|
|
is the pathname to the directory containing the CPU's JSON
|
|
files, relative to the directory containing the mapfile.csv
|
|
|
|
Type:
|
|
indicates whether the events or "core" or "uncore" events.
|
|
|
|
|
|
Eg:
|
|
|
|
$ grep Silvermont tools/perf/pmu-events/arch/x86/mapfile.csv
|
|
GenuineIntel-6-37,V13,Silvermont_core,core
|
|
GenuineIntel-6-4D,V13,Silvermont_core,core
|
|
GenuineIntel-6-4C,V13,Silvermont_core,core
|
|
|
|
i.e the three CPU models use the JSON files (i.e PMU events) listed
|
|
in the directory 'tools/perf/pmu-events/arch/x86/Silvermont_core'.
|