forked from Minki/linux
c05f3642f4
Pull perf updates from Ingo Molnar: "The main updates in this cycle were: - Lots of perf tooling changes too voluminous to list (big perf trace and perf stat improvements, lots of libtraceevent reorganization, etc.), so I'll list the authors and refer to the changelog for details: Benjamin Peterson, Jérémie Galarneau, Kim Phillips, Peter Zijlstra, Ravi Bangoria, Sangwon Hong, Sean V Kelley, Steven Rostedt, Thomas Gleixner, Ding Xiang, Eduardo Habkost, Thomas Richter, Andi Kleen, Sanskriti Sharma, Adrian Hunter, Tzvetomir Stoyanov, Arnaldo Carvalho de Melo, Jiri Olsa. ... with the bulk of the changes written by Jiri Olsa, Tzvetomir Stoyanov and Arnaldo Carvalho de Melo. - Continued intel_rdt work with a focus on playing well with perf events. This also imported some non-perf RDT work due to dependencies. (Reinette Chatre) - Implement counter freezing for Arch Perfmon v4 (Skylake and newer). This allows to speed up the PMI handler by avoiding unnecessary MSR writes and make it more accurate. (Andi Kleen) - kprobes cleanups and simplification (Masami Hiramatsu) - Intel Goldmont PMU updates (Kan Liang) - ... plus misc other fixes and updates" * 'perf-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (155 commits) kprobes/x86: Use preempt_enable() in optimized_callback() x86/intel_rdt: Prevent pseudo-locking from using stale pointers kprobes, x86/ptrace.h: Make regs_get_kernel_stack_nth() not fault on bad stack perf/x86/intel: Export mem events only if there's PEBS support x86/cpu: Drop pointless static qualifier in punit_dev_state_show() x86/intel_rdt: Fix initial allocation to consider CDP x86/intel_rdt: CBM overlap should also check for overlap with CDP peer x86/intel_rdt: Introduce utility to obtain CDP peer tools lib traceevent, perf tools: Move struct tep_handler definition in a local header file tools lib traceevent: Separate out tep_strerror() for strerror_r() issues perf python: More portable way to make CFLAGS work with clang perf python: Make clang_has_option() work on Python 3 perf tools: Free temporary 'sys' string in read_event_files() perf tools: Avoid double free in read_event_file() perf tools: Free 'printk' string in parse_ftrace_printk() perf tools: Cleanup trace-event-info 'tdata' leak perf strbuf: Match va_{add,copy} with va_end perf test: S390 does not support watchpoints in test 22 perf auxtrace: Include missing asm/bitsperlong.h to get BITS_PER_LONG tools include: Adopt linux/bits.h ... |
||
---|---|---|
.. | ||
arch | ||
Build | ||
jevents.c | ||
jevents.h | ||
jsmn.c | ||
jsmn.h | ||
json.c | ||
json.h | ||
pmu-events.h | ||
README |
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'.