2011-08-30 23:41:05 +00:00
|
|
|
/*
|
|
|
|
* Performance events x86 architecture header
|
|
|
|
*
|
|
|
|
* Copyright (C) 2008 Thomas Gleixner <tglx@linutronix.de>
|
|
|
|
* Copyright (C) 2008-2009 Red Hat, Inc., Ingo Molnar
|
|
|
|
* Copyright (C) 2009 Jaswinder Singh Rajput
|
|
|
|
* Copyright (C) 2009 Advanced Micro Devices, Inc., Robert Richter
|
2015-11-16 10:08:45 +00:00
|
|
|
* Copyright (C) 2008-2009 Red Hat, Inc., Peter Zijlstra
|
2011-08-30 23:41:05 +00:00
|
|
|
* Copyright (C) 2009 Intel Corporation, <markus.t.metzger@intel.com>
|
|
|
|
* Copyright (C) 2009 Google, Inc., Stephane Eranian
|
|
|
|
*
|
|
|
|
* For licencing details see kernel-base/COPYING
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/perf_event.h>
|
|
|
|
|
2021-10-15 01:15:57 +00:00
|
|
|
#include <asm/fpu/xstate.h>
|
2017-12-04 14:07:49 +00:00
|
|
|
#include <asm/intel_ds.h>
|
perf/x86: Register hybrid PMUs
Different hybrid PMUs have different PMU capabilities and events. Perf
should registers a dedicated PMU for each of them.
To check the X86 event, perf has to go through all possible hybrid pmus.
All the hybrid PMUs are registered at boot time. Before the
registration, add intel_pmu_check_hybrid_pmus() to check and update the
counters information, the event constraints, the extra registers and the
unique capabilities for each hybrid PMUs.
Postpone the display of the PMU information and HW check to
CPU_STARTING, because the boot CPU is the only online CPU in the
init_hw_perf_events(). Perf doesn't know the availability of the other
PMUs. Perf should display the PMU information only if the counters of
the PMU are available.
One type of CPUs may be all offline. For this case, users can still
observe the PMU in /sys/devices, but its CPU mask is 0.
All hybrid PMUs have capability PERF_PMU_CAP_HETEROGENEOUS_CPUS.
The PMU name for hybrid PMUs will be "cpu_XXX", which will be assigned
later in a separated patch.
The PMU type id for the core PMU is still PERF_TYPE_RAW. For the other
hybrid PMUs, the PMU type id is not hard code.
The event->cpu must be compatitable with the supported CPUs of the PMU.
Add a check in the x86_pmu_event_init().
The events in a group must be from the same type of hybrid PMU.
The fake cpuc used in the validation must be from the supported CPU of
the event->pmu.
Perf may not retrieve a valid core type from get_this_hybrid_cpu_type().
For example, ADL may have an alternative configuration. With that
configuration, Perf cannot retrieve the core type from the CPUID leaf
0x1a. Add a platform specific get_hybrid_cpu_type(). If the generic way
fails, invoke the platform specific get_hybrid_cpu_type().
Suggested-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/1618237865-33448-17-git-send-email-kan.liang@linux.intel.com
2021-04-12 14:30:56 +00:00
|
|
|
#include <asm/cpu.h>
|
2017-12-04 14:07:49 +00:00
|
|
|
|
2015-12-02 01:01:00 +00:00
|
|
|
/* To enable MSR tracing please use the generic trace points. */
|
2012-05-14 13:25:34 +00:00
|
|
|
|
2011-08-30 23:41:05 +00:00
|
|
|
/*
|
|
|
|
* | NHM/WSM | SNB |
|
|
|
|
* register -------------------------------
|
|
|
|
* | HT | no HT | HT | no HT |
|
|
|
|
*-----------------------------------------
|
|
|
|
* offcore | core | core | cpu | core |
|
|
|
|
* lbr_sel | core | core | cpu | core |
|
|
|
|
* ld_lat | cpu | core | cpu | core |
|
|
|
|
*-----------------------------------------
|
|
|
|
*
|
|
|
|
* Given that there is a small number of shared regs,
|
|
|
|
* we can pre-allocate their slot in the per-cpu
|
|
|
|
* per-core reg tables.
|
|
|
|
*/
|
|
|
|
enum extra_reg_type {
|
|
|
|
EXTRA_REG_NONE = -1, /* not used */
|
|
|
|
|
|
|
|
EXTRA_REG_RSP_0 = 0, /* offcore_response_0 */
|
|
|
|
EXTRA_REG_RSP_1 = 1, /* offcore_response_1 */
|
2012-02-09 22:20:53 +00:00
|
|
|
EXTRA_REG_LBR = 2, /* lbr_select */
|
2013-01-24 15:10:32 +00:00
|
|
|
EXTRA_REG_LDLAT = 3, /* ld_lat_threshold */
|
2015-09-09 21:53:59 +00:00
|
|
|
EXTRA_REG_FE = 4, /* fe_* */
|
2011-08-30 23:41:05 +00:00
|
|
|
|
|
|
|
EXTRA_REG_MAX /* number of entries needed */
|
|
|
|
};
|
|
|
|
|
|
|
|
struct event_constraint {
|
|
|
|
union {
|
|
|
|
unsigned long idxmsk[BITS_TO_LONGS(X86_PMC_IDX_MAX)];
|
|
|
|
u64 idxmsk64;
|
|
|
|
};
|
2019-04-02 19:45:04 +00:00
|
|
|
u64 code;
|
|
|
|
u64 cmask;
|
|
|
|
int weight;
|
|
|
|
int overlap;
|
|
|
|
int flags;
|
|
|
|
unsigned int size;
|
2011-08-30 23:41:05 +00:00
|
|
|
};
|
perf/x86: Remove PERF_X86_EVENT_COMMITTED
The flag PERF_X86_EVENT_COMMITTED is used to find uncommitted events
for which to call put_event_constraint() when scheduling fails.
These are the newly added events to the list, and must form, per
definition, the tail of cpuc->event_list[]. By computing the list
index of the last successfull schedule, then iteration can start there
and the flag is redundant.
There are only 3 callers of x86_schedule_events(), notably:
- x86_pmu_add()
- x86_pmu_commit_txn()
- validate_group()
For x86_pmu_add(), cpuc->n_events isn't updated until after
schedule_events() succeeds, therefore cpuc->n_events points to the
desired index.
For x86_pmu_commit_txn(), cpuc->n_events is updated, but we can
trivially compute the desired value with cpuc->n_txn -- the number of
events added in this transaction.
For validate_group(), we can make the rule for x86_pmu_add() work by
simply setting cpuc->n_events to 0 before calling schedule_events().
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Stephane Eranian <eranian@google.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-03-14 11:58:52 +00:00
|
|
|
|
2019-04-02 19:45:04 +00:00
|
|
|
static inline bool constraint_match(struct event_constraint *c, u64 ecode)
|
|
|
|
{
|
|
|
|
return ((ecode & c->cmask) - c->code) <= (u64)c->size;
|
|
|
|
}
|
|
|
|
|
2013-01-24 15:10:32 +00:00
|
|
|
/*
|
2013-06-20 16:42:54 +00:00
|
|
|
* struct hw_perf_event.flags flags
|
2013-01-24 15:10:32 +00:00
|
|
|
*/
|
2015-04-15 18:14:53 +00:00
|
|
|
#define PERF_X86_EVENT_PEBS_LDLAT 0x0001 /* ld+ldlat data address sampling */
|
|
|
|
#define PERF_X86_EVENT_PEBS_ST 0x0002 /* st data address sampling */
|
|
|
|
#define PERF_X86_EVENT_PEBS_ST_HSW 0x0004 /* haswell style datala, store */
|
perf/x86: Remove PERF_X86_EVENT_COMMITTED
The flag PERF_X86_EVENT_COMMITTED is used to find uncommitted events
for which to call put_event_constraint() when scheduling fails.
These are the newly added events to the list, and must form, per
definition, the tail of cpuc->event_list[]. By computing the list
index of the last successfull schedule, then iteration can start there
and the flag is redundant.
There are only 3 callers of x86_schedule_events(), notably:
- x86_pmu_add()
- x86_pmu_commit_txn()
- validate_group()
For x86_pmu_add(), cpuc->n_events isn't updated until after
schedule_events() succeeds, therefore cpuc->n_events points to the
desired index.
For x86_pmu_commit_txn(), cpuc->n_events is updated, but we can
trivially compute the desired value with cpuc->n_txn -- the number of
events added in this transaction.
For validate_group(), we can make the rule for x86_pmu_add() work by
simply setting cpuc->n_events to 0 before calling schedule_events().
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Stephane Eranian <eranian@google.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-03-14 11:58:52 +00:00
|
|
|
#define PERF_X86_EVENT_PEBS_LD_HSW 0x0008 /* haswell style datala, load */
|
|
|
|
#define PERF_X86_EVENT_PEBS_NA_HSW 0x0010 /* haswell style datala, unknown */
|
|
|
|
#define PERF_X86_EVENT_EXCL 0x0020 /* HT exclusivity on counter */
|
|
|
|
#define PERF_X86_EVENT_DYNAMIC 0x0040 /* dynamic alloc'd constraint */
|
|
|
|
#define PERF_X86_EVENT_RDPMC_ALLOWED 0x0080 /* grant rdpmc permission */
|
|
|
|
#define PERF_X86_EVENT_EXCL_ACCT 0x0100 /* accounted EXCL event */
|
|
|
|
#define PERF_X86_EVENT_AUTO_RELOAD 0x0200 /* use PEBS auto-reload */
|
|
|
|
#define PERF_X86_EVENT_LARGE_PEBS 0x0400 /* use large PEBS */
|
perf/x86/intel: Support PEBS output to PT
If PEBS declares ability to output its data to Intel PT stream, use the
aux_output attribute bit to enable PEBS data output to PT. This requires
a PT event to be present and scheduled in the same context. Unlike the
DS area, the kernel does not extract PEBS records from the PT stream to
generate corresponding records in the perf stream, because that would
require real time in-kernel PT decoding, which is not feasible. The PMI,
however, can still be used.
The output setting is per-CPU, so all PEBS events must be either writing
to PT or to the DS area, therefore, in case of conflict, the conflicting
event will fail to schedule, allowing the rotation logic to alternate
between the PEBS->PT and PEBS->DS events.
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: kan.liang@linux.intel.com
Link: https://lkml.kernel.org/r/20190806084606.4021-3-alexander.shishkin@linux.intel.com
2019-08-06 08:46:01 +00:00
|
|
|
#define PERF_X86_EVENT_PEBS_VIA_PT 0x0800 /* use PT buffer for PEBS */
|
2019-11-14 18:37:19 +00:00
|
|
|
#define PERF_X86_EVENT_PAIR 0x1000 /* Large Increment per Cycle */
|
2020-06-13 08:09:50 +00:00
|
|
|
#define PERF_X86_EVENT_LBR_SELECT 0x2000 /* Save/Restore MSR_LBR_SELECT */
|
perf/x86/intel: Generic support for hardware TopDown metrics
Intro
=====
The TopDown Microarchitecture Analysis (TMA) Method is a structured
analysis methodology to identify critical performance bottlenecks in
out-of-order processors. Current perf has supported the method.
The method works well, but there is one problem. To collect the TopDown
events, several GP counters have to be used. If a user wants to collect
other events at the same time, the multiplexing probably be triggered,
which impacts the accuracy.
To free up the scarce GP counters, the hardware TopDown metrics feature
is introduced from Ice Lake. The hardware implements an additional
"metrics" register and a new Fixed Counter 3 that measures pipeline
"slots". The TopDown events can be calculated from them instead.
Events
======
The level 1 TopDown has four metrics. There is no event-code assigned to
the TopDown metrics. Four metric events are exported as separate perf
events, which map to the internal "metrics" counter register. Those
events do not exist in hardware, but can be allocated by the scheduler.
For the event mapping, a special 0x00 event code is used, which is
reserved for fake events. The metric events start from umask 0x10.
When setting up the metric events, they point to the Fixed Counter 3.
They have to be specially handled.
- Add the update_topdown_event() callback to read the additional metrics
MSR and generate the metrics.
- Add the set_topdown_event_period() callback to initialize metrics MSR
and the fixed counter 3.
- Add a variable n_metric_event to track the number of the accepted
metrics events. The sharing between multiple users of the same metric
without multiplexing is not allowed.
- Only enable/disable the fixed counter 3 when there are no other active
TopDown events, which avoid the unnecessary writing of the fixed
control register.
- Disable the PMU when reading the metrics event. The metrics MSR and
the fixed counter 3 are read separately. The values may be modified by
an NMI.
All four metric events don't support sampling. Since they will be
handled specially for event update, a flag PERF_X86_EVENT_TOPDOWN is
introduced to indicate this case.
The slots event can support both sampling and counting.
For counting, the flag is also applied.
For sampling, it will be handled normally as other normal events.
Groups
======
The slots event is required in a Topdown group.
To avoid reading the METRICS register multiple times, the metrics and
slots value can only be updated by slots event in a group.
All active slots and metrics events will be updated one time.
Therefore, the slots event must be before any metric events in a Topdown
group.
NMI
======
The METRICS related register may be overflow. The bit 48 of the STATUS
register will be set. If so, PERF_METRICS and Fixed counter 3 are
required to be reset. The patch also update all active slots and
metrics events in the NMI handler.
The update_topdown_event() has to read two registers separately. The
values may be modified by an NMI. PMU has to be disabled before calling
the function.
RDPMC
======
RDPMC is temporarily disabled. A later patch will enable it.
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20200723171117.9918-9-kan.liang@linux.intel.com
2020-07-23 17:11:11 +00:00
|
|
|
#define PERF_X86_EVENT_TOPDOWN 0x4000 /* Count Topdown slots/metrics events */
|
perf/x86/intel: Add perf core PMU support for Sapphire Rapids
Add perf core PMU support for the Intel Sapphire Rapids server, which is
the successor of the Intel Ice Lake server. The enabling code is based
on Ice Lake, but there are several new features introduced.
The event encoding is changed and simplified, e.g., the event codes
which are below 0x90 are restricted to counters 0-3. The event codes
which above 0x90 are likely to have no restrictions. The event
constraints, extra_regs(), and hardware cache events table are changed
accordingly.
A new Precise Distribution (PDist) facility is introduced, which
further minimizes the skid when a precise event is programmed on the GP
counter 0. Enable the Precise Distribution (PDist) facility with :ppp
event. For this facility to work, the period must be initialized with a
value larger than 127. Add spr_limit_period() to apply the limit for
:ppp event.
Two new data source fields, data block & address block, are added in the
PEBS Memory Info Record for the load latency event. To enable the
feature,
- An auxiliary event has to be enabled together with the load latency
event on Sapphire Rapids. A new flag PMU_FL_MEM_LOADS_AUX is
introduced to indicate the case. A new event, mem-loads-aux, is
exposed to sysfs for the user tool.
Add a check in hw_config(). If the auxiliary event is not detected,
return an unique error -ENODATA.
- The union perf_mem_data_src is extended to support the new fields.
- Ice Lake and earlier models do not support block information, but the
fields may be set by HW on some machines. Add pebs_no_block to
explicitly indicate the previous platforms which don't support the new
block fields. Accessing the new block fields are ignored on those
platforms.
A new store Latency facility is introduced, which leverages the PEBS
facility where it can provide additional information about sampled
stores. The additional information includes the data address, memory
auxiliary info (e.g. Data Source, STLB miss) and the latency of the
store access. To enable the facility, the new event (0x02cd) has to be
programed on the GP counter 0. A new flag PERF_X86_EVENT_PEBS_STLAT is
introduced to indicate the event. The store_latency_data() is introduced
to parse the memory auxiliary info.
The layout of access latency field of PEBS Memory Info Record has been
changed. Two latency, instruction latency (bit 15:0) and cache access
latency (bit 47:32) are recorded.
- The cache access latency is similar to previous memory access latency.
For loads, the latency starts by the actual cache access until the
data is returned by the memory subsystem.
For stores, the latency starts when the demand write accesses the L1
data cache and lasts until the cacheline write is completed in the
memory subsystem.
The cache access latency is stored in low 32bits of the sample type
PERF_SAMPLE_WEIGHT_STRUCT.
- The instruction latency starts by the dispatch of the load operation
for execution and lasts until completion of the instruction it belongs
to.
Add a new flag PMU_FL_INSTR_LATENCY to indicate the instruction
latency support. The instruction latency is stored in the bit 47:32
of the sample type PERF_SAMPLE_WEIGHT_STRUCT.
Extends the PERF_METRICS MSR to feature TMA method level 2 metrics. The
lower half of the register is the TMA level 1 metrics (legacy). The
upper half is also divided into four 8-bit fields for the new level 2
metrics. Expose all eight Topdown metrics events to user space.
The full description for the SPR features can be found at Intel
Architecture Instruction Set Extensions and Future Features
Programming Reference, 319433-041.
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/1611873611-156687-5-git-send-email-kan.liang@linux.intel.com
2021-01-28 22:40:10 +00:00
|
|
|
#define PERF_X86_EVENT_PEBS_STLAT 0x8000 /* st+stlat data address sampling */
|
perf/x86/intel: Generic support for hardware TopDown metrics
Intro
=====
The TopDown Microarchitecture Analysis (TMA) Method is a structured
analysis methodology to identify critical performance bottlenecks in
out-of-order processors. Current perf has supported the method.
The method works well, but there is one problem. To collect the TopDown
events, several GP counters have to be used. If a user wants to collect
other events at the same time, the multiplexing probably be triggered,
which impacts the accuracy.
To free up the scarce GP counters, the hardware TopDown metrics feature
is introduced from Ice Lake. The hardware implements an additional
"metrics" register and a new Fixed Counter 3 that measures pipeline
"slots". The TopDown events can be calculated from them instead.
Events
======
The level 1 TopDown has four metrics. There is no event-code assigned to
the TopDown metrics. Four metric events are exported as separate perf
events, which map to the internal "metrics" counter register. Those
events do not exist in hardware, but can be allocated by the scheduler.
For the event mapping, a special 0x00 event code is used, which is
reserved for fake events. The metric events start from umask 0x10.
When setting up the metric events, they point to the Fixed Counter 3.
They have to be specially handled.
- Add the update_topdown_event() callback to read the additional metrics
MSR and generate the metrics.
- Add the set_topdown_event_period() callback to initialize metrics MSR
and the fixed counter 3.
- Add a variable n_metric_event to track the number of the accepted
metrics events. The sharing between multiple users of the same metric
without multiplexing is not allowed.
- Only enable/disable the fixed counter 3 when there are no other active
TopDown events, which avoid the unnecessary writing of the fixed
control register.
- Disable the PMU when reading the metrics event. The metrics MSR and
the fixed counter 3 are read separately. The values may be modified by
an NMI.
All four metric events don't support sampling. Since they will be
handled specially for event update, a flag PERF_X86_EVENT_TOPDOWN is
introduced to indicate this case.
The slots event can support both sampling and counting.
For counting, the flag is also applied.
For sampling, it will be handled normally as other normal events.
Groups
======
The slots event is required in a Topdown group.
To avoid reading the METRICS register multiple times, the metrics and
slots value can only be updated by slots event in a group.
All active slots and metrics events will be updated one time.
Therefore, the slots event must be before any metric events in a Topdown
group.
NMI
======
The METRICS related register may be overflow. The bit 48 of the STATUS
register will be set. If so, PERF_METRICS and Fixed counter 3 are
required to be reset. The patch also update all active slots and
metrics events in the NMI handler.
The update_topdown_event() has to read two registers separately. The
values may be modified by an NMI. PMU has to be disabled before calling
the function.
RDPMC
======
RDPMC is temporarily disabled. A later patch will enable it.
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20200723171117.9918-9-kan.liang@linux.intel.com
2020-07-23 17:11:11 +00:00
|
|
|
|
|
|
|
static inline bool is_topdown_count(struct perf_event *event)
|
|
|
|
{
|
|
|
|
return event->hw.flags & PERF_X86_EVENT_TOPDOWN;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline bool is_metric_event(struct perf_event *event)
|
|
|
|
{
|
|
|
|
u64 config = event->attr.config;
|
|
|
|
|
|
|
|
return ((config & ARCH_PERFMON_EVENTSEL_EVENT) == 0) &&
|
|
|
|
((config & INTEL_ARCH_EVENT_MASK) >= INTEL_TD_METRIC_RETIRING) &&
|
|
|
|
((config & INTEL_ARCH_EVENT_MASK) <= INTEL_TD_METRIC_MAX);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline bool is_slots_event(struct perf_event *event)
|
|
|
|
{
|
|
|
|
return (event->attr.config & INTEL_ARCH_EVENT_MASK) == INTEL_TD_SLOTS;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline bool is_topdown_event(struct perf_event *event)
|
|
|
|
{
|
|
|
|
return is_metric_event(event) || is_slots_event(event);
|
|
|
|
}
|
2011-08-30 23:41:05 +00:00
|
|
|
|
|
|
|
struct amd_nb {
|
|
|
|
int nb_id; /* NorthBridge id */
|
|
|
|
int refcnt; /* reference count */
|
|
|
|
struct perf_event *owners[X86_PMC_IDX_MAX];
|
|
|
|
struct event_constraint event_constraints[X86_PMC_IDX_MAX];
|
|
|
|
};
|
|
|
|
|
perf/x86: Fix spurious NMI with PEBS Load Latency event
Spurious NMIs will be observed with the following command:
while :; do
perf record -bae "cpu/umask=0x01,event=0xcd,ldlat=0x80/pp"
-e "cpu/umask=0x03,event=0x0/"
-e "cpu/umask=0x02,event=0x0/"
-e cycles,branches,cache-misses
-e cache-references -- sleep 10
done
The bug was introduced by commit:
8077eca079a2 ("perf/x86/pebs: Add workaround for broken OVFL status on HSW+")
That commit clears the status bits for the counters used for PEBS
events, by masking the whole 64 bits pebs_enabled. However, only the
low 32 bits of both status and pebs_enabled are reserved for PEBS-able
counters.
For status bits 32-34 are fixed counter overflow bits. For
pebs_enabled bits 32-34 are for PEBS Load Latency.
In the test case, the PEBS Load Latency event and fixed counter event
could overflow at the same time. The fixed counter overflow bit will
be cleared by mistake. Once it is cleared, the fixed counter overflow
never be processed, which finally trigger spurious NMI.
Correct the PEBS enabled mask by ignoring the non-PEBS bits.
Signed-off-by: Kan Liang <kan.liang@intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Fixes: 8077eca079a2 ("perf/x86/pebs: Add workaround for broken OVFL status on HSW+")
Link: http://lkml.kernel.org/r/1491333246-3965-1-git-send-email-kan.liang@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-04-04 19:14:06 +00:00
|
|
|
#define PEBS_COUNTER_MASK ((1ULL << MAX_PEBS_EVENTS) - 1)
|
perf/x86/intel: Support PEBS output to PT
If PEBS declares ability to output its data to Intel PT stream, use the
aux_output attribute bit to enable PEBS data output to PT. This requires
a PT event to be present and scheduled in the same context. Unlike the
DS area, the kernel does not extract PEBS records from the PT stream to
generate corresponding records in the perf stream, because that would
require real time in-kernel PT decoding, which is not feasible. The PMI,
however, can still be used.
The output setting is per-CPU, so all PEBS events must be either writing
to PT or to the DS area, therefore, in case of conflict, the conflicting
event will fail to schedule, allowing the rotation logic to alternate
between the PEBS->PT and PEBS->DS events.
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: kan.liang@linux.intel.com
Link: https://lkml.kernel.org/r/20190806084606.4021-3-alexander.shishkin@linux.intel.com
2019-08-06 08:46:01 +00:00
|
|
|
#define PEBS_PMI_AFTER_EACH_RECORD BIT_ULL(60)
|
|
|
|
#define PEBS_OUTPUT_OFFSET 61
|
|
|
|
#define PEBS_OUTPUT_MASK (3ull << PEBS_OUTPUT_OFFSET)
|
|
|
|
#define PEBS_OUTPUT_PT (1ull << PEBS_OUTPUT_OFFSET)
|
|
|
|
#define PEBS_VIA_PT_MASK (PEBS_OUTPUT_PT | PEBS_PMI_AFTER_EACH_RECORD)
|
2011-08-30 23:41:05 +00:00
|
|
|
|
perf/x86/intel: Implement batched PEBS interrupt handling (large PEBS interrupt threshold)
PEBS always had the capability to log samples to its buffers without
an interrupt. Traditionally perf has not used this but always set the
PEBS threshold to one.
For frequently occurring events (like cycles or branches or load/store)
this in term requires using a relatively high sampling period to avoid
overloading the system, by only processing PMIs. This in term increases
sampling error.
For the common cases we still need to use the PMI because the PEBS
hardware has various limitations. The biggest one is that it can not
supply a callgraph. It also requires setting a fixed period, as the
hardware does not support adaptive period. Another issue is that it
cannot supply a time stamp and some other options. To supply a TID it
requires flushing on context switch. It can however supply the IP, the
load/store address, TSX information, registers, and some other things.
So we can make PEBS work for some specific cases, basically as long as
you can do without a callgraph and can set the period you can use this
new PEBS mode.
The main benefit is the ability to support much lower sampling period
(down to -c 1000) without extensive overhead.
One use cases is for example to increase the resolution of the c2c tool.
Another is double checking when you suspect the standard sampling has
too much sampling error.
Some numbers on the overhead, using cycle soak, comparing the elapsed
time from "kernbench -M -H" between plain (threshold set to one) and
multi (large threshold).
The test command for plain:
"perf record --time -e cycles:p -c $period -- kernbench -M -H"
The test command for multi:
"perf record --no-time -e cycles:p -c $period -- kernbench -M -H"
( The only difference of test command between multi and plain is time
stamp options. Since time stamp is not supported by large PEBS
threshold, it can be used as a flag to indicate if large threshold is
enabled during the test. )
period plain(Sec) multi(Sec) Delta
10003 32.7 16.5 16.2
20003 30.2 16.2 14.0
40003 18.6 14.1 4.5
80003 16.8 14.6 2.2
100003 16.9 14.1 2.8
800003 15.4 15.7 -0.3
1000003 15.3 15.2 0.2
2000003 15.3 15.1 0.1
With periods below 100003, plain (threshold one) cause much more
overhead. With 10003 sampling period, the Elapsed Time for multi is
even 2X faster than plain.
Signed-off-by: Yan, Zheng <zheng.z.yan@intel.com>
Signed-off-by: Kan Liang <kan.liang@intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: acme@infradead.org
Cc: eranian@google.com
Link: http://lkml.kernel.org/r/1430940834-8964-5-git-send-email-kan.liang@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-05-06 19:33:50 +00:00
|
|
|
/*
|
|
|
|
* Flags PEBS can handle without an PMI.
|
|
|
|
*
|
2015-05-06 19:33:51 +00:00
|
|
|
* TID can only be handled by flushing at context switch.
|
2017-08-31 21:46:30 +00:00
|
|
|
* REGS_USER can be handled for events limited to ring 3.
|
2015-05-06 19:33:51 +00:00
|
|
|
*
|
perf/x86/intel: Implement batched PEBS interrupt handling (large PEBS interrupt threshold)
PEBS always had the capability to log samples to its buffers without
an interrupt. Traditionally perf has not used this but always set the
PEBS threshold to one.
For frequently occurring events (like cycles or branches or load/store)
this in term requires using a relatively high sampling period to avoid
overloading the system, by only processing PMIs. This in term increases
sampling error.
For the common cases we still need to use the PMI because the PEBS
hardware has various limitations. The biggest one is that it can not
supply a callgraph. It also requires setting a fixed period, as the
hardware does not support adaptive period. Another issue is that it
cannot supply a time stamp and some other options. To supply a TID it
requires flushing on context switch. It can however supply the IP, the
load/store address, TSX information, registers, and some other things.
So we can make PEBS work for some specific cases, basically as long as
you can do without a callgraph and can set the period you can use this
new PEBS mode.
The main benefit is the ability to support much lower sampling period
(down to -c 1000) without extensive overhead.
One use cases is for example to increase the resolution of the c2c tool.
Another is double checking when you suspect the standard sampling has
too much sampling error.
Some numbers on the overhead, using cycle soak, comparing the elapsed
time from "kernbench -M -H" between plain (threshold set to one) and
multi (large threshold).
The test command for plain:
"perf record --time -e cycles:p -c $period -- kernbench -M -H"
The test command for multi:
"perf record --no-time -e cycles:p -c $period -- kernbench -M -H"
( The only difference of test command between multi and plain is time
stamp options. Since time stamp is not supported by large PEBS
threshold, it can be used as a flag to indicate if large threshold is
enabled during the test. )
period plain(Sec) multi(Sec) Delta
10003 32.7 16.5 16.2
20003 30.2 16.2 14.0
40003 18.6 14.1 4.5
80003 16.8 14.6 2.2
100003 16.9 14.1 2.8
800003 15.4 15.7 -0.3
1000003 15.3 15.2 0.2
2000003 15.3 15.1 0.1
With periods below 100003, plain (threshold one) cause much more
overhead. With 10003 sampling period, the Elapsed Time for multi is
even 2X faster than plain.
Signed-off-by: Yan, Zheng <zheng.z.yan@intel.com>
Signed-off-by: Kan Liang <kan.liang@intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: acme@infradead.org
Cc: eranian@google.com
Link: http://lkml.kernel.org/r/1430940834-8964-5-git-send-email-kan.liang@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-05-06 19:33:50 +00:00
|
|
|
*/
|
2018-03-12 14:45:37 +00:00
|
|
|
#define LARGE_PEBS_FLAGS \
|
2015-05-06 19:33:51 +00:00
|
|
|
(PERF_SAMPLE_IP | PERF_SAMPLE_TID | PERF_SAMPLE_ADDR | \
|
perf/x86/intel: Implement batched PEBS interrupt handling (large PEBS interrupt threshold)
PEBS always had the capability to log samples to its buffers without
an interrupt. Traditionally perf has not used this but always set the
PEBS threshold to one.
For frequently occurring events (like cycles or branches or load/store)
this in term requires using a relatively high sampling period to avoid
overloading the system, by only processing PMIs. This in term increases
sampling error.
For the common cases we still need to use the PMI because the PEBS
hardware has various limitations. The biggest one is that it can not
supply a callgraph. It also requires setting a fixed period, as the
hardware does not support adaptive period. Another issue is that it
cannot supply a time stamp and some other options. To supply a TID it
requires flushing on context switch. It can however supply the IP, the
load/store address, TSX information, registers, and some other things.
So we can make PEBS work for some specific cases, basically as long as
you can do without a callgraph and can set the period you can use this
new PEBS mode.
The main benefit is the ability to support much lower sampling period
(down to -c 1000) without extensive overhead.
One use cases is for example to increase the resolution of the c2c tool.
Another is double checking when you suspect the standard sampling has
too much sampling error.
Some numbers on the overhead, using cycle soak, comparing the elapsed
time from "kernbench -M -H" between plain (threshold set to one) and
multi (large threshold).
The test command for plain:
"perf record --time -e cycles:p -c $period -- kernbench -M -H"
The test command for multi:
"perf record --no-time -e cycles:p -c $period -- kernbench -M -H"
( The only difference of test command between multi and plain is time
stamp options. Since time stamp is not supported by large PEBS
threshold, it can be used as a flag to indicate if large threshold is
enabled during the test. )
period plain(Sec) multi(Sec) Delta
10003 32.7 16.5 16.2
20003 30.2 16.2 14.0
40003 18.6 14.1 4.5
80003 16.8 14.6 2.2
100003 16.9 14.1 2.8
800003 15.4 15.7 -0.3
1000003 15.3 15.2 0.2
2000003 15.3 15.1 0.1
With periods below 100003, plain (threshold one) cause much more
overhead. With 10003 sampling period, the Elapsed Time for multi is
even 2X faster than plain.
Signed-off-by: Yan, Zheng <zheng.z.yan@intel.com>
Signed-off-by: Kan Liang <kan.liang@intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: acme@infradead.org
Cc: eranian@google.com
Link: http://lkml.kernel.org/r/1430940834-8964-5-git-send-email-kan.liang@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-05-06 19:33:50 +00:00
|
|
|
PERF_SAMPLE_ID | PERF_SAMPLE_CPU | PERF_SAMPLE_STREAM_ID | \
|
|
|
|
PERF_SAMPLE_DATA_SRC | PERF_SAMPLE_IDENTIFIER | \
|
2017-08-31 21:46:30 +00:00
|
|
|
PERF_SAMPLE_TRANSACTION | PERF_SAMPLE_PHYS_ADDR | \
|
2018-02-01 08:38:12 +00:00
|
|
|
PERF_SAMPLE_REGS_INTR | PERF_SAMPLE_REGS_USER | \
|
2020-10-01 13:57:49 +00:00
|
|
|
PERF_SAMPLE_PERIOD | PERF_SAMPLE_CODE_PAGE_SIZE)
|
perf/x86/intel: Implement batched PEBS interrupt handling (large PEBS interrupt threshold)
PEBS always had the capability to log samples to its buffers without
an interrupt. Traditionally perf has not used this but always set the
PEBS threshold to one.
For frequently occurring events (like cycles or branches or load/store)
this in term requires using a relatively high sampling period to avoid
overloading the system, by only processing PMIs. This in term increases
sampling error.
For the common cases we still need to use the PMI because the PEBS
hardware has various limitations. The biggest one is that it can not
supply a callgraph. It also requires setting a fixed period, as the
hardware does not support adaptive period. Another issue is that it
cannot supply a time stamp and some other options. To supply a TID it
requires flushing on context switch. It can however supply the IP, the
load/store address, TSX information, registers, and some other things.
So we can make PEBS work for some specific cases, basically as long as
you can do without a callgraph and can set the period you can use this
new PEBS mode.
The main benefit is the ability to support much lower sampling period
(down to -c 1000) without extensive overhead.
One use cases is for example to increase the resolution of the c2c tool.
Another is double checking when you suspect the standard sampling has
too much sampling error.
Some numbers on the overhead, using cycle soak, comparing the elapsed
time from "kernbench -M -H" between plain (threshold set to one) and
multi (large threshold).
The test command for plain:
"perf record --time -e cycles:p -c $period -- kernbench -M -H"
The test command for multi:
"perf record --no-time -e cycles:p -c $period -- kernbench -M -H"
( The only difference of test command between multi and plain is time
stamp options. Since time stamp is not supported by large PEBS
threshold, it can be used as a flag to indicate if large threshold is
enabled during the test. )
period plain(Sec) multi(Sec) Delta
10003 32.7 16.5 16.2
20003 30.2 16.2 14.0
40003 18.6 14.1 4.5
80003 16.8 14.6 2.2
100003 16.9 14.1 2.8
800003 15.4 15.7 -0.3
1000003 15.3 15.2 0.2
2000003 15.3 15.1 0.1
With periods below 100003, plain (threshold one) cause much more
overhead. With 10003 sampling period, the Elapsed Time for multi is
even 2X faster than plain.
Signed-off-by: Yan, Zheng <zheng.z.yan@intel.com>
Signed-off-by: Kan Liang <kan.liang@intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: acme@infradead.org
Cc: eranian@google.com
Link: http://lkml.kernel.org/r/1430940834-8964-5-git-send-email-kan.liang@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-05-06 19:33:50 +00:00
|
|
|
|
2019-04-02 19:44:58 +00:00
|
|
|
#define PEBS_GP_REGS \
|
|
|
|
((1ULL << PERF_REG_X86_AX) | \
|
|
|
|
(1ULL << PERF_REG_X86_BX) | \
|
|
|
|
(1ULL << PERF_REG_X86_CX) | \
|
|
|
|
(1ULL << PERF_REG_X86_DX) | \
|
|
|
|
(1ULL << PERF_REG_X86_DI) | \
|
|
|
|
(1ULL << PERF_REG_X86_SI) | \
|
|
|
|
(1ULL << PERF_REG_X86_SP) | \
|
|
|
|
(1ULL << PERF_REG_X86_BP) | \
|
|
|
|
(1ULL << PERF_REG_X86_IP) | \
|
|
|
|
(1ULL << PERF_REG_X86_FLAGS) | \
|
|
|
|
(1ULL << PERF_REG_X86_R8) | \
|
|
|
|
(1ULL << PERF_REG_X86_R9) | \
|
|
|
|
(1ULL << PERF_REG_X86_R10) | \
|
|
|
|
(1ULL << PERF_REG_X86_R11) | \
|
|
|
|
(1ULL << PERF_REG_X86_R12) | \
|
|
|
|
(1ULL << PERF_REG_X86_R13) | \
|
|
|
|
(1ULL << PERF_REG_X86_R14) | \
|
|
|
|
(1ULL << PERF_REG_X86_R15))
|
2017-08-31 21:46:30 +00:00
|
|
|
|
2011-08-30 23:41:05 +00:00
|
|
|
/*
|
|
|
|
* Per register state.
|
|
|
|
*/
|
|
|
|
struct er_account {
|
perf/x86/intel: Cure bogus unwind from PEBS entries
Vince Weaver reported that perf_fuzzer + KASAN detects that PEBS event
unwinds sometimes do 'weird' things. In particular, we seemed to be
ending up unwinding from random places on the NMI stack.
While it was somewhat expected that the event record BP,SP would not
match the interrupt BP,SP in that the interrupt is strictly later than
the record event, it was overlooked that it could be on an already
overwritten stack.
Therefore, don't copy the recorded BP,SP over the interrupted BP,SP
when we need stack unwinds.
Note that its still possible the unwind doesn't full match the actual
event, as its entirely possible to have done an (I)RET between record
and interrupt, but on average it should still point in the general
direction of where the event came from. Also, it's the best we can do,
considering.
The particular scenario that triggered the bogus NMI stack unwind was
a PEBS event with very short period, upon enabling the event at the
tail of the PMI handler (FREEZE_ON_PMI is not used), it instantly
triggers a record (while still on the NMI stack) which in turn
triggers the next PMI. This then causes back-to-back NMIs and we'll
try and unwind the stack-frame from the last NMI, which obviously is
now overwritten by our own.
Analyzed-by: Josh Poimboeuf <jpoimboe@redhat.com>
Reported-by: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@gmail.com>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: davej@codemonkey.org.uk <davej@codemonkey.org.uk>
Cc: dvyukov@google.com <dvyukov@google.com>
Cc: stable@vger.kernel.org
Fixes: ca037701a025 ("perf, x86: Add PEBS infrastructure")
Link: http://lkml.kernel.org/r/20161117171731.GV3157@twins.programming.kicks-ass.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-11-17 17:17:31 +00:00
|
|
|
raw_spinlock_t lock; /* per-core: protect structure */
|
2011-08-30 23:41:05 +00:00
|
|
|
u64 config; /* extra MSR config */
|
|
|
|
u64 reg; /* extra MSR number */
|
|
|
|
atomic_t ref; /* reference count */
|
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Per core/cpu state
|
|
|
|
*
|
|
|
|
* Used to coordinate shared registers between HT threads or
|
|
|
|
* among events on a single PMU.
|
|
|
|
*/
|
|
|
|
struct intel_shared_regs {
|
|
|
|
struct er_account regs[EXTRA_REG_MAX];
|
|
|
|
int refcnt; /* per-core: #HT threads */
|
|
|
|
unsigned core_id; /* per-core: core id */
|
|
|
|
};
|
|
|
|
|
2014-11-17 19:06:57 +00:00
|
|
|
enum intel_excl_state_type {
|
|
|
|
INTEL_EXCL_UNUSED = 0, /* counter is unused */
|
|
|
|
INTEL_EXCL_SHARED = 1, /* counter can be used by both threads */
|
|
|
|
INTEL_EXCL_EXCLUSIVE = 2, /* counter can be used by one thread only */
|
|
|
|
};
|
|
|
|
|
|
|
|
struct intel_excl_states {
|
|
|
|
enum intel_excl_state_type state[X86_PMC_IDX_MAX];
|
perf/x86/intel: Implement cross-HT corruption bug workaround
This patch implements a software workaround for a HW erratum
on Intel SandyBridge, IvyBridge and Haswell processors
with Hyperthreading enabled. The errata are documented for
each processor in their respective specification update
documents:
- SandyBridge: BJ122
- IvyBridge: BV98
- Haswell: HSD29
The bug causes silent counter corruption across hyperthreads only
when measuring certain memory events (0xd0, 0xd1, 0xd2, 0xd3).
Counters measuring those events may leak counts to the sibling
counter. For instance, counter 0, thread 0 measuring event 0xd0,
may leak to counter 0, thread 1, regardless of the event measured
there. The size of the leak is not predictible. It all depends on
the workload and the state of each sibling hyper-thread. The
corrupting events do undercount as a consequence of the leak. The
leak is compensated automatically only when the sibling counter measures
the exact same corrupting event AND the workload is on the two threads
is the same. Given, there is no way to guarantee this, a work-around
is necessary. Furthermore, there is a serious problem if the leaked count
is added to a low-occurrence event. In that case the corruption on
the low occurrence event can be very large, e.g., orders of magnitude.
There is no HW or FW workaround for this problem.
The bug is very easy to reproduce on a loaded system.
Here is an example on a Haswell client, where CPU0, CPU4
are siblings. We load the CPUs with a simple triad app
streaming large floating-point vector. We use 0x81d0
corrupting event (MEM_UOPS_RETIRED:ALL_LOADS) and
0x20cc (ROB_MISC_EVENTS:LBR_INSERTS). Given we are not
using the LBR, the 0x20cc event should be zero.
$ taskset -c 0 triad &
$ taskset -c 4 triad &
$ perf stat -a -C 0 -e r81d0 sleep 100 &
$ perf stat -a -C 4 -r20cc sleep 10
Performance counter stats for 'system wide':
139 277 291 r20cc
10,000969126 seconds time elapsed
In this example, 0x81d0 and r20cc ar eusing sinling counters
on CPU0 and CPU4. 0x81d0 leaks into 0x20cc and corrupts it
from 0 to 139 millions occurrences.
This patch provides a software workaround to this problem by modifying the
way events are scheduled onto counters by the kernel. The patch forces
cross-thread mutual exclusion between counters in case a corrupting event
is measured by one of the hyper-threads. If thread 0, counter 0 is measuring
event 0xd0, then nothing can be measured on counter 0, thread 1. If no corrupting
event is measured on any hyper-thread, event scheduling proceeds as before.
The same example run with the workaround enabled, yield the correct answer:
$ taskset -c 0 triad &
$ taskset -c 4 triad &
$ perf stat -a -C 0 -e r81d0 sleep 100 &
$ perf stat -a -C 4 -r20cc sleep 10
Performance counter stats for 'system wide':
0 r20cc
10,000969126 seconds time elapsed
The patch does provide correctness for all non-corrupting events. It does not
"repatriate" the leaked counts back to the leaking counter. This is planned
for a second patch series. This patch series makes this repatriation more
easy by guaranteeing the sibling counter is not measuring any useful event.
The patch introduces dynamic constraints for events. That means that events which
did not have constraints, i.e., could be measured on any counters, may now be
constrained to a subset of the counters depending on what is going on the sibling
thread. The algorithm is similar to a cache coherency protocol. We call it XSU
in reference to Exclusive, Shared, Unused, the 3 possible states of a PMU
counter.
As a consequence of the workaround, users may see an increased amount of event
multiplexing, even in situtations where there are fewer events than counters
measured on a CPU.
Patch has been tested on all three impacted processors. Note that when
HT is off, there is no corruption. However, the workaround is still enabled,
yet not costing too much. Adding a dynamic detection of HT on turned out to
be complex are requiring too much to code to be justified.
This patch addresses the issue when PEBS is not used. A subsequent patch
fixes the problem when PEBS is used.
Signed-off-by: Maria Dimakopoulou <maria.n.dimakopoulou@gmail.com>
[spinlock_t -> raw_spinlock_t]
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Stephane Eranian <eranian@google.com>
Cc: bp@alien8.de
Cc: jolsa@redhat.com
Cc: kan.liang@intel.com
Link: http://lkml.kernel.org/r/1416251225-17721-7-git-send-email-eranian@google.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-11-17 19:06:58 +00:00
|
|
|
bool sched_started; /* true if scheduling has started */
|
2014-11-17 19:06:57 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
struct intel_excl_cntrs {
|
|
|
|
raw_spinlock_t lock;
|
|
|
|
|
|
|
|
struct intel_excl_states states[2];
|
|
|
|
|
2015-05-21 08:57:17 +00:00
|
|
|
union {
|
|
|
|
u16 has_exclusive[2];
|
|
|
|
u32 exclusive_present;
|
|
|
|
};
|
|
|
|
|
2014-11-17 19:06:57 +00:00
|
|
|
int refcnt; /* per-core: #HT threads */
|
|
|
|
unsigned core_id; /* per-core: core id */
|
|
|
|
};
|
|
|
|
|
2018-06-05 15:38:46 +00:00
|
|
|
struct x86_perf_task_context;
|
2015-05-10 19:22:44 +00:00
|
|
|
#define MAX_LBR_ENTRIES 32
|
2011-08-30 23:41:05 +00:00
|
|
|
|
2020-07-03 12:49:08 +00:00
|
|
|
enum {
|
|
|
|
LBR_FORMAT_32 = 0x00,
|
|
|
|
LBR_FORMAT_LIP = 0x01,
|
|
|
|
LBR_FORMAT_EIP = 0x02,
|
|
|
|
LBR_FORMAT_EIP_FLAGS = 0x03,
|
|
|
|
LBR_FORMAT_EIP_FLAGS2 = 0x04,
|
|
|
|
LBR_FORMAT_INFO = 0x05,
|
|
|
|
LBR_FORMAT_TIME = 0x06,
|
|
|
|
LBR_FORMAT_MAX_KNOWN = LBR_FORMAT_TIME,
|
|
|
|
};
|
|
|
|
|
2014-11-17 19:06:54 +00:00
|
|
|
enum {
|
|
|
|
X86_PERF_KFREE_SHARED = 0,
|
|
|
|
X86_PERF_KFREE_EXCL = 1,
|
|
|
|
X86_PERF_KFREE_MAX
|
|
|
|
};
|
|
|
|
|
2011-08-30 23:41:05 +00:00
|
|
|
struct cpu_hw_events {
|
|
|
|
/*
|
|
|
|
* Generic x86 PMC bits
|
|
|
|
*/
|
|
|
|
struct perf_event *events[X86_PMC_IDX_MAX]; /* in counter order */
|
|
|
|
unsigned long active_mask[BITS_TO_LONGS(X86_PMC_IDX_MAX)];
|
perf/x86: Reset the dirty counter to prevent the leak for an RDPMC task
The counter value of a perf task may leak to another RDPMC task.
For example, a perf stat task as below is running on CPU 0.
perf stat -e 'branches,cycles' -- taskset -c 0 ./workload
In the meantime, an RDPMC task, which is also running on CPU 0, may read
the GP counters periodically. (The RDPMC task creates a fixed event,
but read four GP counters.)
$./rdpmc_read_all_counters
index 0x0 value 0x8001e5970f99
index 0x1 value 0x8005d750edb6
index 0x2 value 0x0
index 0x3 value 0x0
index 0x0 value 0x8002358e48a5
index 0x1 value 0x8006bd1e3bc9
index 0x2 value 0x0
index 0x3 value 0x0
It is a potential security issue. Once the attacker knows what the other
thread is counting. The PerfMon counter can be used as a side-channel to
attack cryptosystems.
The counter value of the perf stat task leaks to the RDPMC task because
perf never clears the counter when it's stopped.
Three methods were considered to address the issue.
- Unconditionally reset the counter in x86_pmu_del(). It can bring extra
overhead even when there is no RDPMC task running.
- Only reset the un-assigned dirty counters when the RDPMC task is
scheduled in via sched_task(). It fails for the below case.
Thread A Thread B
clone(CLONE_THREAD) --->
set_affine(0)
set_affine(1)
while (!event-enabled)
;
event = perf_event_open()
mmap(event)
ioctl(event, IOC_ENABLE); --->
RDPMC
Counters are still leaked to the thread B.
- Only reset the un-assigned dirty counters before updating the CR4.PCE
bit. The method is implemented here.
The dirty counter is a counter, on which the assigned event has been
deleted, but the counter is not reset. To track the dirty counters,
add a 'dirty' variable in the struct cpu_hw_events.
The security issue can only be found with an RDPMC task. To enable the
RDMPC, the CR4.PCE bit has to be updated. Add a
perf_clear_dirty_counters() right before updating the CR4.PCE bit to
clear the existing dirty counters. Only the current un-assigned dirty
counters are reset, because the RDPMC assigned dirty counters will be
updated soon.
After applying the patch,
$ ./rdpmc_read_all_counters
index 0x0 value 0x0
index 0x1 value 0x0
index 0x2 value 0x0
index 0x3 value 0x0
index 0x0 value 0x0
index 0x1 value 0x0
index 0x2 value 0x0
index 0x3 value 0x0
Performance
The performance of a context switch only be impacted when there are two
or more perf users and one of the users must be an RDPMC user. In other
cases, there is no performance impact.
The worst-case occurs when there are two users: the RDPMC user only
uses one counter; while the other user uses all available counters.
When the RDPMC task is scheduled in, all the counters, other than the
RDPMC assigned one, have to be reset.
Test results for the worst-case, using a modified lat_ctx as measured
on an Ice Lake platform, which has 8 GP and 3 FP counters (ignoring
SLOTS).
lat_ctx -s 128K -N 1000 processes 2
Without the patch:
The context switch time is 4.97 us
With the patch:
The context switch time is 5.16 us
There is ~4% performance drop for the context switching time in the
worst-case.
Suggested-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/1623693582-187370-1-git-send-email-kan.liang@linux.intel.com
2021-06-14 17:59:42 +00:00
|
|
|
unsigned long dirty[BITS_TO_LONGS(X86_PMC_IDX_MAX)];
|
2011-08-30 23:41:05 +00:00
|
|
|
int enabled;
|
|
|
|
|
2014-02-24 11:26:21 +00:00
|
|
|
int n_events; /* the # of events in the below arrays */
|
|
|
|
int n_added; /* the # last events in the below arrays;
|
|
|
|
they've never been enabled yet */
|
|
|
|
int n_txn; /* the # last events in the below arrays;
|
|
|
|
added in the current transaction */
|
2020-10-05 08:09:06 +00:00
|
|
|
int n_txn_pair;
|
perf/x86: Fix n_metric for cancelled txn
When a group that has TopDown members is failed to be scheduled, any
later TopDown groups will not return valid values.
Here is an example.
A background perf that occupies all the GP counters and the fixed
counter 1.
$perf stat -e "{cycles,cycles,cycles,cycles,cycles,cycles,cycles,
cycles,cycles}:D" -a
A user monitors a TopDown group. It works well, because the fixed
counter 3 and the PERF_METRICS are available.
$perf stat -x, --topdown -- ./workload
retiring,bad speculation,frontend bound,backend bound,
18.0,16.1,40.4,25.5,
Then the user tries to monitor a group that has TopDown members.
Because of the cycles event, the group is failed to be scheduled.
$perf stat -x, -e '{slots,topdown-retiring,topdown-be-bound,
topdown-fe-bound,topdown-bad-spec,cycles}'
-- ./workload
<not counted>,,slots,0,0.00,,
<not counted>,,topdown-retiring,0,0.00,,
<not counted>,,topdown-be-bound,0,0.00,,
<not counted>,,topdown-fe-bound,0,0.00,,
<not counted>,,topdown-bad-spec,0,0.00,,
<not counted>,,cycles,0,0.00,,
The user tries to monitor a TopDown group again. It doesn't work anymore.
$perf stat -x, --topdown -- ./workload
,,,,,
In a txn, cancel_txn() is to truncate the event_list for a canceled
group and update the number of events added in this transaction.
However, the number of TopDown events added in this transaction is not
updated. The kernel will probably fail to add new Topdown events.
Fixes: 7b2c05a15d29 ("perf/x86/intel: Generic support for hardware TopDown metrics")
Reported-by: Andi Kleen <ak@linux.intel.com>
Reported-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Tested-by: Kan Liang <kan.liang@linux.intel.com>
Link: https://lkml.kernel.org/r/20201005082611.GH2628@hirez.programming.kicks-ass.net
2020-10-05 08:10:24 +00:00
|
|
|
int n_txn_metric;
|
2011-08-30 23:41:05 +00:00
|
|
|
int assign[X86_PMC_IDX_MAX]; /* event to counter assignment */
|
|
|
|
u64 tags[X86_PMC_IDX_MAX];
|
2015-05-21 08:57:13 +00:00
|
|
|
|
2011-08-30 23:41:05 +00:00
|
|
|
struct perf_event *event_list[X86_PMC_IDX_MAX]; /* in enabled order */
|
2015-05-21 08:57:13 +00:00
|
|
|
struct event_constraint *event_constraint[X86_PMC_IDX_MAX];
|
|
|
|
|
2015-05-21 08:57:17 +00:00
|
|
|
int n_excl; /* the number of exclusive events */
|
2011-08-30 23:41:05 +00:00
|
|
|
|
2015-09-04 03:07:45 +00:00
|
|
|
unsigned int txn_flags;
|
2012-06-05 13:30:31 +00:00
|
|
|
int is_fake;
|
2011-08-30 23:41:05 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Intel DebugStore bits
|
|
|
|
*/
|
|
|
|
struct debug_store *ds;
|
2017-12-04 14:07:50 +00:00
|
|
|
void *ds_pebs_vaddr;
|
|
|
|
void *ds_bts_vaddr;
|
2011-08-30 23:41:05 +00:00
|
|
|
u64 pebs_enabled;
|
2016-07-06 16:02:43 +00:00
|
|
|
int n_pebs;
|
|
|
|
int n_large_pebs;
|
perf/x86/intel: Support PEBS output to PT
If PEBS declares ability to output its data to Intel PT stream, use the
aux_output attribute bit to enable PEBS data output to PT. This requires
a PT event to be present and scheduled in the same context. Unlike the
DS area, the kernel does not extract PEBS records from the PT stream to
generate corresponding records in the perf stream, because that would
require real time in-kernel PT decoding, which is not feasible. The PMI,
however, can still be used.
The output setting is per-CPU, so all PEBS events must be either writing
to PT or to the DS area, therefore, in case of conflict, the conflicting
event will fail to schedule, allowing the rotation logic to alternate
between the PEBS->PT and PEBS->DS events.
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: kan.liang@linux.intel.com
Link: https://lkml.kernel.org/r/20190806084606.4021-3-alexander.shishkin@linux.intel.com
2019-08-06 08:46:01 +00:00
|
|
|
int n_pebs_via_pt;
|
|
|
|
int pebs_output;
|
2011-08-30 23:41:05 +00:00
|
|
|
|
perf/x86/intel: Support adaptive PEBS v4
Adaptive PEBS is a new way to report PEBS sampling information. Instead
of a fixed size record for all PEBS events it allows to configure the
PEBS record to only include the information needed. Events can then opt
in to use such an extended record, or stay with a basic record which
only contains the IP.
The major new feature is to support LBRs in PEBS record.
Besides normal LBR, this allows (much faster) large PEBS, while still
supporting callstacks through callstack LBR. So essentially a lot of
profiling can now be done without frequent interrupts, dropping the
overhead significantly.
The main requirement still is to use a period, and not use frequency
mode, because frequency mode requires reevaluating the frequency on each
overflow.
The floating point state (XMM) is also supported, which allows efficient
profiling of FP function arguments.
Introduce specific drain function to handle variable length records.
Use a new callback to parse the new record format, and also handle the
STATUS field now being at a different offset.
Add code to set up the configuration register. Since there is only a
single register, all events either get the full super set of all events,
or only the basic record.
Originally-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Cc: acme@kernel.org
Cc: jolsa@kernel.org
Link: https://lkml.kernel.org/r/20190402194509.2832-6-kan.liang@linux.intel.com
[ Renamed GPRS => GP. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-04-02 19:45:02 +00:00
|
|
|
/* Current super set of events hardware configuration */
|
|
|
|
u64 pebs_data_cfg;
|
|
|
|
u64 active_pebs_data_cfg;
|
|
|
|
int pebs_record_size;
|
|
|
|
|
2011-08-30 23:41:05 +00:00
|
|
|
/*
|
|
|
|
* Intel LBR bits
|
|
|
|
*/
|
|
|
|
int lbr_users;
|
2019-04-02 19:45:03 +00:00
|
|
|
int lbr_pebs_users;
|
2011-08-30 23:41:05 +00:00
|
|
|
struct perf_branch_stack lbr_stack;
|
|
|
|
struct perf_branch_entry lbr_entries[MAX_LBR_ENTRIES];
|
2020-07-03 12:49:15 +00:00
|
|
|
union {
|
|
|
|
struct er_account *lbr_sel;
|
|
|
|
struct er_account *lbr_ctl;
|
|
|
|
};
|
2012-02-09 22:20:58 +00:00
|
|
|
u64 br_sel;
|
2020-07-03 12:49:12 +00:00
|
|
|
void *last_task_ctx;
|
2018-06-05 15:38:46 +00:00
|
|
|
int last_log_id;
|
2020-06-13 08:09:50 +00:00
|
|
|
int lbr_select;
|
2020-07-03 12:49:29 +00:00
|
|
|
void *lbr_xsave;
|
2011-08-30 23:41:05 +00:00
|
|
|
|
2011-10-05 12:01:21 +00:00
|
|
|
/*
|
|
|
|
* Intel host/guest exclude bits
|
|
|
|
*/
|
|
|
|
u64 intel_ctrl_guest_mask;
|
|
|
|
u64 intel_ctrl_host_mask;
|
|
|
|
struct perf_guest_switch_msr guest_switch_msrs[X86_PMC_IDX_MAX];
|
|
|
|
|
2013-09-12 10:53:44 +00:00
|
|
|
/*
|
|
|
|
* Intel checkpoint mask
|
|
|
|
*/
|
|
|
|
u64 intel_cp_status;
|
|
|
|
|
2011-08-30 23:41:05 +00:00
|
|
|
/*
|
|
|
|
* manage shared (per-core, per-cpu) registers
|
|
|
|
* used on Intel NHM/WSM/SNB
|
|
|
|
*/
|
|
|
|
struct intel_shared_regs *shared_regs;
|
2014-11-17 19:06:57 +00:00
|
|
|
/*
|
|
|
|
* manage exclusive counter access between hyperthread
|
|
|
|
*/
|
|
|
|
struct event_constraint *constraint_list; /* in enable order */
|
|
|
|
struct intel_excl_cntrs *excl_cntrs;
|
|
|
|
int excl_thread_id; /* 0 or 1 */
|
2011-08-30 23:41:05 +00:00
|
|
|
|
2019-03-05 21:23:18 +00:00
|
|
|
/*
|
|
|
|
* SKL TSX_FORCE_ABORT shadow
|
|
|
|
*/
|
|
|
|
u64 tfa_shadow;
|
|
|
|
|
perf/x86/intel: Generic support for hardware TopDown metrics
Intro
=====
The TopDown Microarchitecture Analysis (TMA) Method is a structured
analysis methodology to identify critical performance bottlenecks in
out-of-order processors. Current perf has supported the method.
The method works well, but there is one problem. To collect the TopDown
events, several GP counters have to be used. If a user wants to collect
other events at the same time, the multiplexing probably be triggered,
which impacts the accuracy.
To free up the scarce GP counters, the hardware TopDown metrics feature
is introduced from Ice Lake. The hardware implements an additional
"metrics" register and a new Fixed Counter 3 that measures pipeline
"slots". The TopDown events can be calculated from them instead.
Events
======
The level 1 TopDown has four metrics. There is no event-code assigned to
the TopDown metrics. Four metric events are exported as separate perf
events, which map to the internal "metrics" counter register. Those
events do not exist in hardware, but can be allocated by the scheduler.
For the event mapping, a special 0x00 event code is used, which is
reserved for fake events. The metric events start from umask 0x10.
When setting up the metric events, they point to the Fixed Counter 3.
They have to be specially handled.
- Add the update_topdown_event() callback to read the additional metrics
MSR and generate the metrics.
- Add the set_topdown_event_period() callback to initialize metrics MSR
and the fixed counter 3.
- Add a variable n_metric_event to track the number of the accepted
metrics events. The sharing between multiple users of the same metric
without multiplexing is not allowed.
- Only enable/disable the fixed counter 3 when there are no other active
TopDown events, which avoid the unnecessary writing of the fixed
control register.
- Disable the PMU when reading the metrics event. The metrics MSR and
the fixed counter 3 are read separately. The values may be modified by
an NMI.
All four metric events don't support sampling. Since they will be
handled specially for event update, a flag PERF_X86_EVENT_TOPDOWN is
introduced to indicate this case.
The slots event can support both sampling and counting.
For counting, the flag is also applied.
For sampling, it will be handled normally as other normal events.
Groups
======
The slots event is required in a Topdown group.
To avoid reading the METRICS register multiple times, the metrics and
slots value can only be updated by slots event in a group.
All active slots and metrics events will be updated one time.
Therefore, the slots event must be before any metric events in a Topdown
group.
NMI
======
The METRICS related register may be overflow. The bit 48 of the STATUS
register will be set. If so, PERF_METRICS and Fixed counter 3 are
required to be reset. The patch also update all active slots and
metrics events in the NMI handler.
The update_topdown_event() has to read two registers separately. The
values may be modified by an NMI. PMU has to be disabled before calling
the function.
RDPMC
======
RDPMC is temporarily disabled. A later patch will enable it.
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20200723171117.9918-9-kan.liang@linux.intel.com
2020-07-23 17:11:11 +00:00
|
|
|
/*
|
|
|
|
* Perf Metrics
|
|
|
|
*/
|
|
|
|
/* number of accepted metrics events */
|
|
|
|
int n_metric;
|
|
|
|
|
2011-08-30 23:41:05 +00:00
|
|
|
/*
|
|
|
|
* AMD specific bits
|
|
|
|
*/
|
2012-02-29 13:57:32 +00:00
|
|
|
struct amd_nb *amd_nb;
|
|
|
|
/* Inverted mask of bits to clear in the perf_ctr ctrl registers */
|
|
|
|
u64 perf_ctr_virt_mask;
|
perf/x86/amd: Add support for Large Increment per Cycle Events
Description of hardware operation
---------------------------------
The core AMD PMU has a 4-bit wide per-cycle increment for each
performance monitor counter. That works for most events, but
now with AMD Family 17h and above processors, some events can
occur more than 15 times in a cycle. Those events are called
"Large Increment per Cycle" events. In order to count these
events, two adjacent h/w PMCs get their count signals merged
to form 8 bits per cycle total. In addition, the PERF_CTR count
registers are merged to be able to count up to 64 bits.
Normally, events like instructions retired, get programmed on a single
counter like so:
PERF_CTL0 (MSR 0xc0010200) 0x000000000053ff0c # event 0x0c, umask 0xff
PERF_CTR0 (MSR 0xc0010201) 0x0000800000000001 # r/w 48-bit count
The next counter at MSRs 0xc0010202-3 remains unused, or can be used
independently to count something else.
When counting Large Increment per Cycle events, such as FLOPs,
however, we now have to reserve the next counter and program the
PERF_CTL (config) register with the Merge event (0xFFF), like so:
PERF_CTL0 (msr 0xc0010200) 0x000000000053ff03 # FLOPs event, umask 0xff
PERF_CTR0 (msr 0xc0010201) 0x0000800000000001 # rd 64-bit cnt, wr lo 48b
PERF_CTL1 (msr 0xc0010202) 0x0000000f004000ff # Merge event, enable bit
PERF_CTR1 (msr 0xc0010203) 0x0000000000000000 # wr hi 16-bits count
The count is widened from the normal 48-bits to 64 bits by having the
second counter carry the higher 16 bits of the count in its lower 16
bits of its counter register.
The odd counter, e.g., PERF_CTL1, is programmed with the enabled Merge
event before the even counter, PERF_CTL0.
The Large Increment feature is available starting with Family 17h.
For more details, search any Family 17h PPR for the "Large Increment
per Cycle Events" section, e.g., section 2.1.15.3 on p. 173 in this
version:
https://www.amd.com/system/files/TechDocs/56176_ppr_Family_17h_Model_71h_B0_pub_Rev_3.06.zip
Description of software operation
---------------------------------
The following steps are taken in order to support reserving and
enabling the extra counter for Large Increment per Cycle events:
1. In the main x86 scheduler, we reduce the number of available
counters by the number of Large Increment per Cycle events being
scheduled, tracked by a new cpuc variable 'n_pair' and a new
amd_put_event_constraints_f17h(). This improves the counter
scheduler success rate.
2. In perf_assign_events(), if a counter is assigned to a Large
Increment event, we increment the current counter variable, so the
counter used for the Merge event is removed from assignment
consideration by upcoming event assignments.
3. In find_counter(), if a counter has been found for the Large
Increment event, we set the next counter as used, to prevent other
events from using it.
4. We perform steps 2 & 3 also in the x86 scheduler fastpath, i.e.,
we add Merge event accounting to the existing used_mask logic.
5. Finally, we add on the programming of Merge event to the
neighbouring PMC counters in the counter enable/disable{_all}
code paths.
Currently, software does not support a single PMU with mixed 48- and
64-bit counting, so Large increment event counts are limited to 48
bits. In set_period, we zero-out the upper 16 bits of the count, so
the hardware doesn't copy them to the even counter's higher bits.
Simple invocation example showing counting 8 FLOPs per 256-bit/%ymm
vaddps instruction executed in a loop 100 million times:
perf stat -e cpu/fp_ret_sse_avx_ops.all/,cpu/instructions/ <workload>
Performance counter stats for '<workload>':
800,000,000 cpu/fp_ret_sse_avx_ops.all/u
300,042,101 cpu/instructions/u
Prior to this patch, the reported SSE/AVX FLOPs retired count would
be wrong.
[peterz: lots of renames and edits to the code]
Signed-off-by: Kim Phillips <kim.phillips@amd.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
2019-11-14 18:37:20 +00:00
|
|
|
int n_pair; /* Large increment events */
|
2011-08-30 23:41:05 +00:00
|
|
|
|
2014-11-17 19:06:54 +00:00
|
|
|
void *kfree_on_online[X86_PERF_KFREE_MAX];
|
2021-04-12 14:30:43 +00:00
|
|
|
|
|
|
|
struct pmu *pmu;
|
2011-08-30 23:41:05 +00:00
|
|
|
};
|
|
|
|
|
2019-04-02 19:45:04 +00:00
|
|
|
#define __EVENT_CONSTRAINT_RANGE(c, e, n, m, w, o, f) { \
|
2011-08-30 23:41:05 +00:00
|
|
|
{ .idxmsk64 = (n) }, \
|
|
|
|
.code = (c), \
|
2019-04-02 19:45:04 +00:00
|
|
|
.size = (e) - (c), \
|
2011-08-30 23:41:05 +00:00
|
|
|
.cmask = (m), \
|
|
|
|
.weight = (w), \
|
2011-11-18 11:35:22 +00:00
|
|
|
.overlap = (o), \
|
2013-01-24 15:10:27 +00:00
|
|
|
.flags = f, \
|
2011-08-30 23:41:05 +00:00
|
|
|
}
|
|
|
|
|
2019-04-02 19:45:04 +00:00
|
|
|
#define __EVENT_CONSTRAINT(c, n, m, w, o, f) \
|
|
|
|
__EVENT_CONSTRAINT_RANGE(c, c, n, m, w, o, f)
|
|
|
|
|
2011-08-30 23:41:05 +00:00
|
|
|
#define EVENT_CONSTRAINT(c, n, m) \
|
2013-01-24 15:10:27 +00:00
|
|
|
__EVENT_CONSTRAINT(c, n, m, HWEIGHT(n), 0, 0)
|
2011-11-18 11:35:22 +00:00
|
|
|
|
2019-04-02 19:45:04 +00:00
|
|
|
/*
|
|
|
|
* The constraint_match() function only works for 'simple' event codes
|
|
|
|
* and not for extended (AMD64_EVENTSEL_EVENT) events codes.
|
|
|
|
*/
|
|
|
|
#define EVENT_CONSTRAINT_RANGE(c, e, n, m) \
|
|
|
|
__EVENT_CONSTRAINT_RANGE(c, e, n, m, HWEIGHT(n), 0, 0)
|
|
|
|
|
2014-11-17 19:06:57 +00:00
|
|
|
#define INTEL_EXCLEVT_CONSTRAINT(c, n) \
|
|
|
|
__EVENT_CONSTRAINT(c, n, ARCH_PERFMON_EVENTSEL_EVENT, HWEIGHT(n),\
|
|
|
|
0, PERF_X86_EVENT_EXCL)
|
|
|
|
|
2011-11-18 11:35:22 +00:00
|
|
|
/*
|
|
|
|
* The overlap flag marks event constraints with overlapping counter
|
|
|
|
* masks. This is the case if the counter mask of such an event is not
|
|
|
|
* a subset of any other counter mask of a constraint with an equal or
|
|
|
|
* higher weight, e.g.:
|
|
|
|
*
|
|
|
|
* c_overlaps = EVENT_CONSTRAINT_OVERLAP(0, 0x09, 0);
|
|
|
|
* c_another1 = EVENT_CONSTRAINT(0, 0x07, 0);
|
|
|
|
* c_another2 = EVENT_CONSTRAINT(0, 0x38, 0);
|
|
|
|
*
|
|
|
|
* The event scheduler may not select the correct counter in the first
|
|
|
|
* cycle because it needs to know which subsequent events will be
|
|
|
|
* scheduled. It may fail to schedule the events then. So we set the
|
|
|
|
* overlap flag for such constraints to give the scheduler a hint which
|
|
|
|
* events to select for counter rescheduling.
|
|
|
|
*
|
|
|
|
* Care must be taken as the rescheduling algorithm is O(n!) which
|
2016-02-23 23:34:30 +00:00
|
|
|
* will increase scheduling cycles for an over-committed system
|
2011-11-18 11:35:22 +00:00
|
|
|
* dramatically. The number of such EVENT_CONSTRAINT_OVERLAP() macros
|
|
|
|
* and its counter masks must be kept at a minimum.
|
|
|
|
*/
|
|
|
|
#define EVENT_CONSTRAINT_OVERLAP(c, n, m) \
|
2013-01-24 15:10:27 +00:00
|
|
|
__EVENT_CONSTRAINT(c, n, m, HWEIGHT(n), 1, 0)
|
2011-08-30 23:41:05 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Constraint on the Event code.
|
|
|
|
*/
|
|
|
|
#define INTEL_EVENT_CONSTRAINT(c, n) \
|
|
|
|
EVENT_CONSTRAINT(c, n, ARCH_PERFMON_EVENTSEL_EVENT)
|
|
|
|
|
2019-04-02 19:45:04 +00:00
|
|
|
/*
|
|
|
|
* Constraint on a range of Event codes
|
|
|
|
*/
|
|
|
|
#define INTEL_EVENT_CONSTRAINT_RANGE(c, e, n) \
|
|
|
|
EVENT_CONSTRAINT_RANGE(c, e, n, ARCH_PERFMON_EVENTSEL_EVENT)
|
|
|
|
|
2011-08-30 23:41:05 +00:00
|
|
|
/*
|
|
|
|
* Constraint on the Event code + UMask + fixed-mask
|
|
|
|
*
|
|
|
|
* filter mask to validate fixed counter events.
|
|
|
|
* the following filters disqualify for fixed counters:
|
|
|
|
* - inv
|
|
|
|
* - edge
|
|
|
|
* - cnt-mask
|
2013-06-18 00:36:48 +00:00
|
|
|
* - in_tx
|
|
|
|
* - in_tx_checkpointed
|
2011-08-30 23:41:05 +00:00
|
|
|
* The other filters are supported by fixed counters.
|
|
|
|
* The any-thread option is supported starting with v3.
|
|
|
|
*/
|
2013-06-18 00:36:48 +00:00
|
|
|
#define FIXED_EVENT_FLAGS (X86_RAW_EVENT_MASK|HSW_IN_TX|HSW_IN_TX_CHECKPOINTED)
|
2011-08-30 23:41:05 +00:00
|
|
|
#define FIXED_EVENT_CONSTRAINT(c, n) \
|
2013-06-18 00:36:48 +00:00
|
|
|
EVENT_CONSTRAINT(c, (1ULL << (32+n)), FIXED_EVENT_FLAGS)
|
2011-08-30 23:41:05 +00:00
|
|
|
|
2020-07-23 17:11:13 +00:00
|
|
|
/*
|
|
|
|
* The special metric counters do not actually exist. They are calculated from
|
|
|
|
* the combination of the FxCtr3 + MSR_PERF_METRICS.
|
|
|
|
*
|
|
|
|
* The special metric counters are mapped to a dummy offset for the scheduler.
|
|
|
|
* The sharing between multiple users of the same metric without multiplexing
|
|
|
|
* is not allowed, even though the hardware supports that in principle.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#define METRIC_EVENT_CONSTRAINT(c, n) \
|
|
|
|
EVENT_CONSTRAINT(c, (1ULL << (INTEL_PMC_IDX_METRIC_BASE + n)), \
|
|
|
|
INTEL_ARCH_EVENT_MASK)
|
|
|
|
|
2011-08-30 23:41:05 +00:00
|
|
|
/*
|
|
|
|
* Constraint on the Event code + UMask
|
|
|
|
*/
|
|
|
|
#define INTEL_UEVENT_CONSTRAINT(c, n) \
|
|
|
|
EVENT_CONSTRAINT(c, n, INTEL_ARCH_EVENT_MASK)
|
|
|
|
|
2015-11-17 00:21:07 +00:00
|
|
|
/* Constraint on specific umask bit only + event */
|
|
|
|
#define INTEL_UBIT_EVENT_CONSTRAINT(c, n) \
|
|
|
|
EVENT_CONSTRAINT(c, n, ARCH_PERFMON_EVENTSEL_EVENT|(c))
|
|
|
|
|
2014-09-24 14:34:46 +00:00
|
|
|
/* Like UEVENT_CONSTRAINT, but match flags too */
|
|
|
|
#define INTEL_FLAGS_UEVENT_CONSTRAINT(c, n) \
|
|
|
|
EVENT_CONSTRAINT(c, n, INTEL_ARCH_EVENT_MASK|X86_ALL_EVENT_FLAGS)
|
|
|
|
|
perf/x86/intel: Implement cross-HT corruption bug workaround
This patch implements a software workaround for a HW erratum
on Intel SandyBridge, IvyBridge and Haswell processors
with Hyperthreading enabled. The errata are documented for
each processor in their respective specification update
documents:
- SandyBridge: BJ122
- IvyBridge: BV98
- Haswell: HSD29
The bug causes silent counter corruption across hyperthreads only
when measuring certain memory events (0xd0, 0xd1, 0xd2, 0xd3).
Counters measuring those events may leak counts to the sibling
counter. For instance, counter 0, thread 0 measuring event 0xd0,
may leak to counter 0, thread 1, regardless of the event measured
there. The size of the leak is not predictible. It all depends on
the workload and the state of each sibling hyper-thread. The
corrupting events do undercount as a consequence of the leak. The
leak is compensated automatically only when the sibling counter measures
the exact same corrupting event AND the workload is on the two threads
is the same. Given, there is no way to guarantee this, a work-around
is necessary. Furthermore, there is a serious problem if the leaked count
is added to a low-occurrence event. In that case the corruption on
the low occurrence event can be very large, e.g., orders of magnitude.
There is no HW or FW workaround for this problem.
The bug is very easy to reproduce on a loaded system.
Here is an example on a Haswell client, where CPU0, CPU4
are siblings. We load the CPUs with a simple triad app
streaming large floating-point vector. We use 0x81d0
corrupting event (MEM_UOPS_RETIRED:ALL_LOADS) and
0x20cc (ROB_MISC_EVENTS:LBR_INSERTS). Given we are not
using the LBR, the 0x20cc event should be zero.
$ taskset -c 0 triad &
$ taskset -c 4 triad &
$ perf stat -a -C 0 -e r81d0 sleep 100 &
$ perf stat -a -C 4 -r20cc sleep 10
Performance counter stats for 'system wide':
139 277 291 r20cc
10,000969126 seconds time elapsed
In this example, 0x81d0 and r20cc ar eusing sinling counters
on CPU0 and CPU4. 0x81d0 leaks into 0x20cc and corrupts it
from 0 to 139 millions occurrences.
This patch provides a software workaround to this problem by modifying the
way events are scheduled onto counters by the kernel. The patch forces
cross-thread mutual exclusion between counters in case a corrupting event
is measured by one of the hyper-threads. If thread 0, counter 0 is measuring
event 0xd0, then nothing can be measured on counter 0, thread 1. If no corrupting
event is measured on any hyper-thread, event scheduling proceeds as before.
The same example run with the workaround enabled, yield the correct answer:
$ taskset -c 0 triad &
$ taskset -c 4 triad &
$ perf stat -a -C 0 -e r81d0 sleep 100 &
$ perf stat -a -C 4 -r20cc sleep 10
Performance counter stats for 'system wide':
0 r20cc
10,000969126 seconds time elapsed
The patch does provide correctness for all non-corrupting events. It does not
"repatriate" the leaked counts back to the leaking counter. This is planned
for a second patch series. This patch series makes this repatriation more
easy by guaranteeing the sibling counter is not measuring any useful event.
The patch introduces dynamic constraints for events. That means that events which
did not have constraints, i.e., could be measured on any counters, may now be
constrained to a subset of the counters depending on what is going on the sibling
thread. The algorithm is similar to a cache coherency protocol. We call it XSU
in reference to Exclusive, Shared, Unused, the 3 possible states of a PMU
counter.
As a consequence of the workaround, users may see an increased amount of event
multiplexing, even in situtations where there are fewer events than counters
measured on a CPU.
Patch has been tested on all three impacted processors. Note that when
HT is off, there is no corruption. However, the workaround is still enabled,
yet not costing too much. Adding a dynamic detection of HT on turned out to
be complex are requiring too much to code to be justified.
This patch addresses the issue when PEBS is not used. A subsequent patch
fixes the problem when PEBS is used.
Signed-off-by: Maria Dimakopoulou <maria.n.dimakopoulou@gmail.com>
[spinlock_t -> raw_spinlock_t]
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Stephane Eranian <eranian@google.com>
Cc: bp@alien8.de
Cc: jolsa@redhat.com
Cc: kan.liang@intel.com
Link: http://lkml.kernel.org/r/1416251225-17721-7-git-send-email-eranian@google.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-11-17 19:06:58 +00:00
|
|
|
#define INTEL_EXCLUEVT_CONSTRAINT(c, n) \
|
|
|
|
__EVENT_CONSTRAINT(c, n, INTEL_ARCH_EVENT_MASK, \
|
|
|
|
HWEIGHT(n), 0, PERF_X86_EVENT_EXCL)
|
|
|
|
|
2013-01-24 15:10:32 +00:00
|
|
|
#define INTEL_PLD_CONSTRAINT(c, n) \
|
2014-08-11 19:27:10 +00:00
|
|
|
__EVENT_CONSTRAINT(c, n, INTEL_ARCH_EVENT_MASK|X86_ALL_EVENT_FLAGS, \
|
2013-01-24 15:10:32 +00:00
|
|
|
HWEIGHT(n), 0, PERF_X86_EVENT_PEBS_LDLAT)
|
|
|
|
|
perf/x86/intel: Add perf core PMU support for Sapphire Rapids
Add perf core PMU support for the Intel Sapphire Rapids server, which is
the successor of the Intel Ice Lake server. The enabling code is based
on Ice Lake, but there are several new features introduced.
The event encoding is changed and simplified, e.g., the event codes
which are below 0x90 are restricted to counters 0-3. The event codes
which above 0x90 are likely to have no restrictions. The event
constraints, extra_regs(), and hardware cache events table are changed
accordingly.
A new Precise Distribution (PDist) facility is introduced, which
further minimizes the skid when a precise event is programmed on the GP
counter 0. Enable the Precise Distribution (PDist) facility with :ppp
event. For this facility to work, the period must be initialized with a
value larger than 127. Add spr_limit_period() to apply the limit for
:ppp event.
Two new data source fields, data block & address block, are added in the
PEBS Memory Info Record for the load latency event. To enable the
feature,
- An auxiliary event has to be enabled together with the load latency
event on Sapphire Rapids. A new flag PMU_FL_MEM_LOADS_AUX is
introduced to indicate the case. A new event, mem-loads-aux, is
exposed to sysfs for the user tool.
Add a check in hw_config(). If the auxiliary event is not detected,
return an unique error -ENODATA.
- The union perf_mem_data_src is extended to support the new fields.
- Ice Lake and earlier models do not support block information, but the
fields may be set by HW on some machines. Add pebs_no_block to
explicitly indicate the previous platforms which don't support the new
block fields. Accessing the new block fields are ignored on those
platforms.
A new store Latency facility is introduced, which leverages the PEBS
facility where it can provide additional information about sampled
stores. The additional information includes the data address, memory
auxiliary info (e.g. Data Source, STLB miss) and the latency of the
store access. To enable the facility, the new event (0x02cd) has to be
programed on the GP counter 0. A new flag PERF_X86_EVENT_PEBS_STLAT is
introduced to indicate the event. The store_latency_data() is introduced
to parse the memory auxiliary info.
The layout of access latency field of PEBS Memory Info Record has been
changed. Two latency, instruction latency (bit 15:0) and cache access
latency (bit 47:32) are recorded.
- The cache access latency is similar to previous memory access latency.
For loads, the latency starts by the actual cache access until the
data is returned by the memory subsystem.
For stores, the latency starts when the demand write accesses the L1
data cache and lasts until the cacheline write is completed in the
memory subsystem.
The cache access latency is stored in low 32bits of the sample type
PERF_SAMPLE_WEIGHT_STRUCT.
- The instruction latency starts by the dispatch of the load operation
for execution and lasts until completion of the instruction it belongs
to.
Add a new flag PMU_FL_INSTR_LATENCY to indicate the instruction
latency support. The instruction latency is stored in the bit 47:32
of the sample type PERF_SAMPLE_WEIGHT_STRUCT.
Extends the PERF_METRICS MSR to feature TMA method level 2 metrics. The
lower half of the register is the TMA level 1 metrics (legacy). The
upper half is also divided into four 8-bit fields for the new level 2
metrics. Expose all eight Topdown metrics events to user space.
The full description for the SPR features can be found at Intel
Architecture Instruction Set Extensions and Future Features
Programming Reference, 319433-041.
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/1611873611-156687-5-git-send-email-kan.liang@linux.intel.com
2021-01-28 22:40:10 +00:00
|
|
|
#define INTEL_PSD_CONSTRAINT(c, n) \
|
|
|
|
__EVENT_CONSTRAINT(c, n, INTEL_ARCH_EVENT_MASK|X86_ALL_EVENT_FLAGS, \
|
|
|
|
HWEIGHT(n), 0, PERF_X86_EVENT_PEBS_STLAT)
|
|
|
|
|
2013-01-24 15:10:34 +00:00
|
|
|
#define INTEL_PST_CONSTRAINT(c, n) \
|
2014-08-11 19:27:10 +00:00
|
|
|
__EVENT_CONSTRAINT(c, n, INTEL_ARCH_EVENT_MASK|X86_ALL_EVENT_FLAGS, \
|
2013-01-24 15:10:34 +00:00
|
|
|
HWEIGHT(n), 0, PERF_X86_EVENT_PEBS_ST)
|
|
|
|
|
2014-08-11 19:27:10 +00:00
|
|
|
/* Event constraint, but match on all event flags too. */
|
|
|
|
#define INTEL_FLAGS_EVENT_CONSTRAINT(c, n) \
|
2019-05-09 21:45:56 +00:00
|
|
|
EVENT_CONSTRAINT(c, n, ARCH_PERFMON_EVENTSEL_EVENT|X86_ALL_EVENT_FLAGS)
|
2014-08-11 19:27:10 +00:00
|
|
|
|
2019-04-02 19:45:04 +00:00
|
|
|
#define INTEL_FLAGS_EVENT_CONSTRAINT_RANGE(c, e, n) \
|
2019-05-09 21:45:56 +00:00
|
|
|
EVENT_CONSTRAINT_RANGE(c, e, n, ARCH_PERFMON_EVENTSEL_EVENT|X86_ALL_EVENT_FLAGS)
|
2019-04-02 19:45:04 +00:00
|
|
|
|
2014-08-11 19:27:10 +00:00
|
|
|
/* Check only flags, but allow all event/umask */
|
|
|
|
#define INTEL_ALL_EVENT_CONSTRAINT(code, n) \
|
|
|
|
EVENT_CONSTRAINT(code, n, X86_ALL_EVENT_FLAGS)
|
|
|
|
|
|
|
|
/* Check flags and event code, and set the HSW store flag */
|
|
|
|
#define INTEL_FLAGS_EVENT_CONSTRAINT_DATALA_ST(code, n) \
|
|
|
|
__EVENT_CONSTRAINT(code, n, \
|
|
|
|
ARCH_PERFMON_EVENTSEL_EVENT|X86_ALL_EVENT_FLAGS, \
|
|
|
|
HWEIGHT(n), 0, PERF_X86_EVENT_PEBS_ST_HSW)
|
|
|
|
|
|
|
|
/* Check flags and event code, and set the HSW load flag */
|
|
|
|
#define INTEL_FLAGS_EVENT_CONSTRAINT_DATALA_LD(code, n) \
|
2014-11-17 19:07:00 +00:00
|
|
|
__EVENT_CONSTRAINT(code, n, \
|
2014-08-11 19:27:10 +00:00
|
|
|
ARCH_PERFMON_EVENTSEL_EVENT|X86_ALL_EVENT_FLAGS, \
|
|
|
|
HWEIGHT(n), 0, PERF_X86_EVENT_PEBS_LD_HSW)
|
|
|
|
|
2019-04-02 19:45:04 +00:00
|
|
|
#define INTEL_FLAGS_EVENT_CONSTRAINT_DATALA_LD_RANGE(code, end, n) \
|
|
|
|
__EVENT_CONSTRAINT_RANGE(code, end, n, \
|
|
|
|
ARCH_PERFMON_EVENTSEL_EVENT|X86_ALL_EVENT_FLAGS, \
|
|
|
|
HWEIGHT(n), 0, PERF_X86_EVENT_PEBS_LD_HSW)
|
|
|
|
|
2014-11-17 19:07:00 +00:00
|
|
|
#define INTEL_FLAGS_EVENT_CONSTRAINT_DATALA_XLD(code, n) \
|
|
|
|
__EVENT_CONSTRAINT(code, n, \
|
|
|
|
ARCH_PERFMON_EVENTSEL_EVENT|X86_ALL_EVENT_FLAGS, \
|
|
|
|
HWEIGHT(n), 0, \
|
|
|
|
PERF_X86_EVENT_PEBS_LD_HSW|PERF_X86_EVENT_EXCL)
|
|
|
|
|
2014-08-11 19:27:10 +00:00
|
|
|
/* Check flags and event code/umask, and set the HSW store flag */
|
|
|
|
#define INTEL_FLAGS_UEVENT_CONSTRAINT_DATALA_ST(code, n) \
|
|
|
|
__EVENT_CONSTRAINT(code, n, \
|
|
|
|
INTEL_ARCH_EVENT_MASK|X86_ALL_EVENT_FLAGS, \
|
2013-06-18 00:36:52 +00:00
|
|
|
HWEIGHT(n), 0, PERF_X86_EVENT_PEBS_ST_HSW)
|
|
|
|
|
2014-11-17 19:07:00 +00:00
|
|
|
#define INTEL_FLAGS_UEVENT_CONSTRAINT_DATALA_XST(code, n) \
|
|
|
|
__EVENT_CONSTRAINT(code, n, \
|
|
|
|
INTEL_ARCH_EVENT_MASK|X86_ALL_EVENT_FLAGS, \
|
|
|
|
HWEIGHT(n), 0, \
|
|
|
|
PERF_X86_EVENT_PEBS_ST_HSW|PERF_X86_EVENT_EXCL)
|
|
|
|
|
2014-08-11 19:27:10 +00:00
|
|
|
/* Check flags and event code/umask, and set the HSW load flag */
|
|
|
|
#define INTEL_FLAGS_UEVENT_CONSTRAINT_DATALA_LD(code, n) \
|
|
|
|
__EVENT_CONSTRAINT(code, n, \
|
|
|
|
INTEL_ARCH_EVENT_MASK|X86_ALL_EVENT_FLAGS, \
|
|
|
|
HWEIGHT(n), 0, PERF_X86_EVENT_PEBS_LD_HSW)
|
|
|
|
|
2014-11-17 19:07:00 +00:00
|
|
|
#define INTEL_FLAGS_UEVENT_CONSTRAINT_DATALA_XLD(code, n) \
|
|
|
|
__EVENT_CONSTRAINT(code, n, \
|
|
|
|
INTEL_ARCH_EVENT_MASK|X86_ALL_EVENT_FLAGS, \
|
|
|
|
HWEIGHT(n), 0, \
|
|
|
|
PERF_X86_EVENT_PEBS_LD_HSW|PERF_X86_EVENT_EXCL)
|
|
|
|
|
2014-08-11 19:27:10 +00:00
|
|
|
/* Check flags and event code/umask, and set the HSW N/A flag */
|
|
|
|
#define INTEL_FLAGS_UEVENT_CONSTRAINT_DATALA_NA(code, n) \
|
|
|
|
__EVENT_CONSTRAINT(code, n, \
|
2015-11-09 09:24:31 +00:00
|
|
|
INTEL_ARCH_EVENT_MASK|X86_ALL_EVENT_FLAGS, \
|
2014-08-11 19:27:10 +00:00
|
|
|
HWEIGHT(n), 0, PERF_X86_EVENT_PEBS_NA_HSW)
|
|
|
|
|
|
|
|
|
2013-12-04 23:24:37 +00:00
|
|
|
/*
|
|
|
|
* We define the end marker as having a weight of -1
|
|
|
|
* to enable blacklisting of events using a counter bitmask
|
|
|
|
* of zero and thus a weight of zero.
|
|
|
|
* The end marker has a weight that cannot possibly be
|
|
|
|
* obtained from counting the bits in the bitmask.
|
|
|
|
*/
|
|
|
|
#define EVENT_CONSTRAINT_END { .weight = -1 }
|
2011-08-30 23:41:05 +00:00
|
|
|
|
2013-12-04 23:24:37 +00:00
|
|
|
/*
|
|
|
|
* Check for end marker with weight == -1
|
|
|
|
*/
|
2011-08-30 23:41:05 +00:00
|
|
|
#define for_each_event_constraint(e, c) \
|
2013-12-04 23:24:37 +00:00
|
|
|
for ((e) = (c); (e)->weight != -1; (e)++)
|
2011-08-30 23:41:05 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Extra registers for specific events.
|
|
|
|
*
|
|
|
|
* Some events need large masks and require external MSRs.
|
|
|
|
* Those extra MSRs end up being shared for all events on
|
|
|
|
* a PMU and sometimes between PMU of sibling HT threads.
|
|
|
|
* In either case, the kernel needs to handle conflicting
|
|
|
|
* accesses to those extra, shared, regs. The data structure
|
|
|
|
* to manage those registers is stored in cpu_hw_event.
|
|
|
|
*/
|
|
|
|
struct extra_reg {
|
|
|
|
unsigned int event;
|
|
|
|
unsigned int msr;
|
|
|
|
u64 config_mask;
|
|
|
|
u64 valid_mask;
|
|
|
|
int idx; /* per_xxx->regs[] reg index */
|
2014-07-14 19:25:56 +00:00
|
|
|
bool extra_msr_access;
|
2011-08-30 23:41:05 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
#define EVENT_EXTRA_REG(e, ms, m, vm, i) { \
|
2014-07-14 19:25:56 +00:00
|
|
|
.event = (e), \
|
|
|
|
.msr = (ms), \
|
|
|
|
.config_mask = (m), \
|
|
|
|
.valid_mask = (vm), \
|
|
|
|
.idx = EXTRA_REG_##i, \
|
|
|
|
.extra_msr_access = true, \
|
2011-08-30 23:41:05 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
#define INTEL_EVENT_EXTRA_REG(event, msr, vm, idx) \
|
|
|
|
EVENT_EXTRA_REG(event, msr, ARCH_PERFMON_EVENTSEL_EVENT, vm, idx)
|
|
|
|
|
2013-01-24 15:10:32 +00:00
|
|
|
#define INTEL_UEVENT_EXTRA_REG(event, msr, vm, idx) \
|
|
|
|
EVENT_EXTRA_REG(event, msr, ARCH_PERFMON_EVENTSEL_EVENT | \
|
|
|
|
ARCH_PERFMON_EVENTSEL_UMASK, vm, idx)
|
|
|
|
|
|
|
|
#define INTEL_UEVENT_PEBS_LDLAT_EXTRA_REG(c) \
|
|
|
|
INTEL_UEVENT_EXTRA_REG(c, \
|
|
|
|
MSR_PEBS_LD_LAT_THRESHOLD, \
|
|
|
|
0xffff, \
|
|
|
|
LDLAT)
|
|
|
|
|
2011-08-30 23:41:05 +00:00
|
|
|
#define EVENT_EXTRA_END EVENT_EXTRA_REG(0, 0, 0, 0, RSP_0)
|
|
|
|
|
|
|
|
union perf_capabilities {
|
|
|
|
struct {
|
|
|
|
u64 lbr_format:6;
|
|
|
|
u64 pebs_trap:1;
|
|
|
|
u64 pebs_arch_reg:1;
|
|
|
|
u64 pebs_format:4;
|
|
|
|
u64 smm_freeze:1;
|
2013-06-25 15:12:33 +00:00
|
|
|
/*
|
|
|
|
* PMU supports separate counter range for writing
|
|
|
|
* values > 32bit.
|
|
|
|
*/
|
|
|
|
u64 full_width_write:1;
|
perf/x86/intel: Support adaptive PEBS v4
Adaptive PEBS is a new way to report PEBS sampling information. Instead
of a fixed size record for all PEBS events it allows to configure the
PEBS record to only include the information needed. Events can then opt
in to use such an extended record, or stay with a basic record which
only contains the IP.
The major new feature is to support LBRs in PEBS record.
Besides normal LBR, this allows (much faster) large PEBS, while still
supporting callstacks through callstack LBR. So essentially a lot of
profiling can now be done without frequent interrupts, dropping the
overhead significantly.
The main requirement still is to use a period, and not use frequency
mode, because frequency mode requires reevaluating the frequency on each
overflow.
The floating point state (XMM) is also supported, which allows efficient
profiling of FP function arguments.
Introduce specific drain function to handle variable length records.
Use a new callback to parse the new record format, and also handle the
STATUS field now being at a different offset.
Add code to set up the configuration register. Since there is only a
single register, all events either get the full super set of all events,
or only the basic record.
Originally-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Cc: acme@kernel.org
Cc: jolsa@kernel.org
Link: https://lkml.kernel.org/r/20190402194509.2832-6-kan.liang@linux.intel.com
[ Renamed GPRS => GP. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-04-02 19:45:02 +00:00
|
|
|
u64 pebs_baseline:1;
|
2020-07-23 17:11:08 +00:00
|
|
|
u64 perf_metrics:1;
|
perf/x86/intel: Support PEBS output to PT
If PEBS declares ability to output its data to Intel PT stream, use the
aux_output attribute bit to enable PEBS data output to PT. This requires
a PT event to be present and scheduled in the same context. Unlike the
DS area, the kernel does not extract PEBS records from the PT stream to
generate corresponding records in the perf stream, because that would
require real time in-kernel PT decoding, which is not feasible. The PMI,
however, can still be used.
The output setting is per-CPU, so all PEBS events must be either writing
to PT or to the DS area, therefore, in case of conflict, the conflicting
event will fail to schedule, allowing the rotation logic to alternate
between the PEBS->PT and PEBS->DS events.
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: kan.liang@linux.intel.com
Link: https://lkml.kernel.org/r/20190806084606.4021-3-alexander.shishkin@linux.intel.com
2019-08-06 08:46:01 +00:00
|
|
|
u64 pebs_output_pt_available:1;
|
2020-10-28 19:42:47 +00:00
|
|
|
u64 anythread_deprecated:1;
|
2011-08-30 23:41:05 +00:00
|
|
|
};
|
|
|
|
u64 capabilities;
|
|
|
|
};
|
|
|
|
|
2011-12-06 13:07:15 +00:00
|
|
|
struct x86_pmu_quirk {
|
|
|
|
struct x86_pmu_quirk *next;
|
|
|
|
void (*func)(void);
|
|
|
|
};
|
|
|
|
|
2012-03-12 11:44:35 +00:00
|
|
|
union x86_pmu_config {
|
|
|
|
struct {
|
|
|
|
u64 event:8,
|
|
|
|
umask:8,
|
|
|
|
usr:1,
|
|
|
|
os:1,
|
|
|
|
edge:1,
|
|
|
|
pc:1,
|
|
|
|
interrupt:1,
|
|
|
|
__reserved1:1,
|
|
|
|
en:1,
|
|
|
|
inv:1,
|
|
|
|
cmask:8,
|
|
|
|
event2:4,
|
|
|
|
__reserved2:4,
|
|
|
|
go:1,
|
|
|
|
ho:1;
|
|
|
|
} bits;
|
|
|
|
u64 value;
|
|
|
|
};
|
|
|
|
|
|
|
|
#define X86_CONFIG(args...) ((union x86_pmu_config){.bits = {args}}).value
|
|
|
|
|
2015-01-14 12:18:20 +00:00
|
|
|
enum {
|
|
|
|
x86_lbr_exclusive_lbr,
|
2015-01-30 10:40:35 +00:00
|
|
|
x86_lbr_exclusive_bts,
|
2015-01-14 12:18:20 +00:00
|
|
|
x86_lbr_exclusive_pt,
|
|
|
|
x86_lbr_exclusive_max,
|
|
|
|
};
|
|
|
|
|
perf/x86/intel: Hybrid PMU support for perf capabilities
Some platforms, e.g. Alder Lake, have hybrid architecture. Although most
PMU capabilities are the same, there are still some unique PMU
capabilities for different hybrid PMUs. Perf should register a dedicated
pmu for each hybrid PMU.
Add a new struct x86_hybrid_pmu, which saves the dedicated pmu and
capabilities for each hybrid PMU.
The architecture MSR, MSR_IA32_PERF_CAPABILITIES, only indicates the
architecture features which are available on all hybrid PMUs. The
architecture features are stored in the global x86_pmu.intel_cap.
For Alder Lake, the model-specific features are perf metrics and
PEBS-via-PT. The corresponding bits of the global x86_pmu.intel_cap
should be 0 for these two features. Perf should not use the global
intel_cap to check the features on a hybrid system.
Add a dedicated intel_cap in the x86_hybrid_pmu to store the
model-specific capabilities. Use the dedicated intel_cap to replace
the global intel_cap for thse two features. The dedicated intel_cap
will be set in the following "Add Alder Lake Hybrid support" patch.
Add is_hybrid() to distinguish a hybrid system. ADL may have an
alternative configuration. With that configuration, the
X86_FEATURE_HYBRID_CPU is not set. Perf cannot rely on the feature bit.
Add a new static_key_false, perf_is_hybrid, to indicate a hybrid system.
It will be assigned in the following "Add Alder Lake Hybrid support"
patch as well.
Suggested-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/1618237865-33448-5-git-send-email-kan.liang@linux.intel.com
2021-04-12 14:30:44 +00:00
|
|
|
struct x86_hybrid_pmu {
|
|
|
|
struct pmu pmu;
|
perf/x86: Register hybrid PMUs
Different hybrid PMUs have different PMU capabilities and events. Perf
should registers a dedicated PMU for each of them.
To check the X86 event, perf has to go through all possible hybrid pmus.
All the hybrid PMUs are registered at boot time. Before the
registration, add intel_pmu_check_hybrid_pmus() to check and update the
counters information, the event constraints, the extra registers and the
unique capabilities for each hybrid PMUs.
Postpone the display of the PMU information and HW check to
CPU_STARTING, because the boot CPU is the only online CPU in the
init_hw_perf_events(). Perf doesn't know the availability of the other
PMUs. Perf should display the PMU information only if the counters of
the PMU are available.
One type of CPUs may be all offline. For this case, users can still
observe the PMU in /sys/devices, but its CPU mask is 0.
All hybrid PMUs have capability PERF_PMU_CAP_HETEROGENEOUS_CPUS.
The PMU name for hybrid PMUs will be "cpu_XXX", which will be assigned
later in a separated patch.
The PMU type id for the core PMU is still PERF_TYPE_RAW. For the other
hybrid PMUs, the PMU type id is not hard code.
The event->cpu must be compatitable with the supported CPUs of the PMU.
Add a check in the x86_pmu_event_init().
The events in a group must be from the same type of hybrid PMU.
The fake cpuc used in the validation must be from the supported CPU of
the event->pmu.
Perf may not retrieve a valid core type from get_this_hybrid_cpu_type().
For example, ADL may have an alternative configuration. With that
configuration, Perf cannot retrieve the core type from the CPUID leaf
0x1a. Add a platform specific get_hybrid_cpu_type(). If the generic way
fails, invoke the platform specific get_hybrid_cpu_type().
Suggested-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/1618237865-33448-17-git-send-email-kan.liang@linux.intel.com
2021-04-12 14:30:56 +00:00
|
|
|
const char *name;
|
|
|
|
u8 cpu_type;
|
|
|
|
cpumask_t supported_cpus;
|
perf/x86/intel: Hybrid PMU support for perf capabilities
Some platforms, e.g. Alder Lake, have hybrid architecture. Although most
PMU capabilities are the same, there are still some unique PMU
capabilities for different hybrid PMUs. Perf should register a dedicated
pmu for each hybrid PMU.
Add a new struct x86_hybrid_pmu, which saves the dedicated pmu and
capabilities for each hybrid PMU.
The architecture MSR, MSR_IA32_PERF_CAPABILITIES, only indicates the
architecture features which are available on all hybrid PMUs. The
architecture features are stored in the global x86_pmu.intel_cap.
For Alder Lake, the model-specific features are perf metrics and
PEBS-via-PT. The corresponding bits of the global x86_pmu.intel_cap
should be 0 for these two features. Perf should not use the global
intel_cap to check the features on a hybrid system.
Add a dedicated intel_cap in the x86_hybrid_pmu to store the
model-specific capabilities. Use the dedicated intel_cap to replace
the global intel_cap for thse two features. The dedicated intel_cap
will be set in the following "Add Alder Lake Hybrid support" patch.
Add is_hybrid() to distinguish a hybrid system. ADL may have an
alternative configuration. With that configuration, the
X86_FEATURE_HYBRID_CPU is not set. Perf cannot rely on the feature bit.
Add a new static_key_false, perf_is_hybrid, to indicate a hybrid system.
It will be assigned in the following "Add Alder Lake Hybrid support"
patch as well.
Suggested-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/1618237865-33448-5-git-send-email-kan.liang@linux.intel.com
2021-04-12 14:30:44 +00:00
|
|
|
union perf_capabilities intel_cap;
|
2021-04-12 14:30:45 +00:00
|
|
|
u64 intel_ctrl;
|
2021-04-12 14:30:46 +00:00
|
|
|
int max_pebs_events;
|
|
|
|
int num_counters;
|
|
|
|
int num_counters_fixed;
|
2021-04-12 14:30:47 +00:00
|
|
|
struct event_constraint unconstrained;
|
2021-04-12 14:30:48 +00:00
|
|
|
|
|
|
|
u64 hw_cache_event_ids
|
|
|
|
[PERF_COUNT_HW_CACHE_MAX]
|
|
|
|
[PERF_COUNT_HW_CACHE_OP_MAX]
|
|
|
|
[PERF_COUNT_HW_CACHE_RESULT_MAX];
|
|
|
|
u64 hw_cache_extra_regs
|
|
|
|
[PERF_COUNT_HW_CACHE_MAX]
|
|
|
|
[PERF_COUNT_HW_CACHE_OP_MAX]
|
|
|
|
[PERF_COUNT_HW_CACHE_RESULT_MAX];
|
2021-04-12 14:30:49 +00:00
|
|
|
struct event_constraint *event_constraints;
|
|
|
|
struct event_constraint *pebs_constraints;
|
2021-04-12 14:30:50 +00:00
|
|
|
struct extra_reg *extra_regs;
|
2021-08-03 13:25:28 +00:00
|
|
|
|
|
|
|
unsigned int late_ack :1,
|
|
|
|
mid_ack :1,
|
|
|
|
enabled_ack :1;
|
perf/x86/intel: Hybrid PMU support for perf capabilities
Some platforms, e.g. Alder Lake, have hybrid architecture. Although most
PMU capabilities are the same, there are still some unique PMU
capabilities for different hybrid PMUs. Perf should register a dedicated
pmu for each hybrid PMU.
Add a new struct x86_hybrid_pmu, which saves the dedicated pmu and
capabilities for each hybrid PMU.
The architecture MSR, MSR_IA32_PERF_CAPABILITIES, only indicates the
architecture features which are available on all hybrid PMUs. The
architecture features are stored in the global x86_pmu.intel_cap.
For Alder Lake, the model-specific features are perf metrics and
PEBS-via-PT. The corresponding bits of the global x86_pmu.intel_cap
should be 0 for these two features. Perf should not use the global
intel_cap to check the features on a hybrid system.
Add a dedicated intel_cap in the x86_hybrid_pmu to store the
model-specific capabilities. Use the dedicated intel_cap to replace
the global intel_cap for thse two features. The dedicated intel_cap
will be set in the following "Add Alder Lake Hybrid support" patch.
Add is_hybrid() to distinguish a hybrid system. ADL may have an
alternative configuration. With that configuration, the
X86_FEATURE_HYBRID_CPU is not set. Perf cannot rely on the feature bit.
Add a new static_key_false, perf_is_hybrid, to indicate a hybrid system.
It will be assigned in the following "Add Alder Lake Hybrid support"
patch as well.
Suggested-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/1618237865-33448-5-git-send-email-kan.liang@linux.intel.com
2021-04-12 14:30:44 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
static __always_inline struct x86_hybrid_pmu *hybrid_pmu(struct pmu *pmu)
|
|
|
|
{
|
|
|
|
return container_of(pmu, struct x86_hybrid_pmu, pmu);
|
|
|
|
}
|
|
|
|
|
|
|
|
extern struct static_key_false perf_is_hybrid;
|
|
|
|
#define is_hybrid() static_branch_unlikely(&perf_is_hybrid)
|
|
|
|
|
|
|
|
#define hybrid(_pmu, _field) \
|
|
|
|
(*({ \
|
|
|
|
typeof(&x86_pmu._field) __Fp = &x86_pmu._field; \
|
|
|
|
\
|
|
|
|
if (is_hybrid() && (_pmu)) \
|
|
|
|
__Fp = &hybrid_pmu(_pmu)->_field; \
|
|
|
|
\
|
|
|
|
__Fp; \
|
|
|
|
}))
|
|
|
|
|
2021-04-12 14:30:47 +00:00
|
|
|
#define hybrid_var(_pmu, _var) \
|
|
|
|
(*({ \
|
|
|
|
typeof(&_var) __Fp = &_var; \
|
|
|
|
\
|
|
|
|
if (is_hybrid() && (_pmu)) \
|
|
|
|
__Fp = &hybrid_pmu(_pmu)->_var; \
|
|
|
|
\
|
|
|
|
__Fp; \
|
|
|
|
}))
|
|
|
|
|
2021-08-03 13:25:28 +00:00
|
|
|
#define hybrid_bit(_pmu, _field) \
|
|
|
|
({ \
|
|
|
|
bool __Fp = x86_pmu._field; \
|
|
|
|
\
|
|
|
|
if (is_hybrid() && (_pmu)) \
|
|
|
|
__Fp = hybrid_pmu(_pmu)->_field; \
|
|
|
|
\
|
|
|
|
__Fp; \
|
|
|
|
})
|
|
|
|
|
perf/x86: Register hybrid PMUs
Different hybrid PMUs have different PMU capabilities and events. Perf
should registers a dedicated PMU for each of them.
To check the X86 event, perf has to go through all possible hybrid pmus.
All the hybrid PMUs are registered at boot time. Before the
registration, add intel_pmu_check_hybrid_pmus() to check and update the
counters information, the event constraints, the extra registers and the
unique capabilities for each hybrid PMUs.
Postpone the display of the PMU information and HW check to
CPU_STARTING, because the boot CPU is the only online CPU in the
init_hw_perf_events(). Perf doesn't know the availability of the other
PMUs. Perf should display the PMU information only if the counters of
the PMU are available.
One type of CPUs may be all offline. For this case, users can still
observe the PMU in /sys/devices, but its CPU mask is 0.
All hybrid PMUs have capability PERF_PMU_CAP_HETEROGENEOUS_CPUS.
The PMU name for hybrid PMUs will be "cpu_XXX", which will be assigned
later in a separated patch.
The PMU type id for the core PMU is still PERF_TYPE_RAW. For the other
hybrid PMUs, the PMU type id is not hard code.
The event->cpu must be compatitable with the supported CPUs of the PMU.
Add a check in the x86_pmu_event_init().
The events in a group must be from the same type of hybrid PMU.
The fake cpuc used in the validation must be from the supported CPU of
the event->pmu.
Perf may not retrieve a valid core type from get_this_hybrid_cpu_type().
For example, ADL may have an alternative configuration. With that
configuration, Perf cannot retrieve the core type from the CPUID leaf
0x1a. Add a platform specific get_hybrid_cpu_type(). If the generic way
fails, invoke the platform specific get_hybrid_cpu_type().
Suggested-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/1618237865-33448-17-git-send-email-kan.liang@linux.intel.com
2021-04-12 14:30:56 +00:00
|
|
|
enum hybrid_pmu_type {
|
|
|
|
hybrid_big = 0x40,
|
|
|
|
hybrid_small = 0x20,
|
|
|
|
|
|
|
|
hybrid_big_small = hybrid_big | hybrid_small,
|
|
|
|
};
|
|
|
|
|
2021-04-12 14:31:00 +00:00
|
|
|
#define X86_HYBRID_PMU_ATOM_IDX 0
|
|
|
|
#define X86_HYBRID_PMU_CORE_IDX 1
|
|
|
|
|
|
|
|
#define X86_HYBRID_NUM_PMUS 2
|
|
|
|
|
2011-08-30 23:41:05 +00:00
|
|
|
/*
|
|
|
|
* struct x86_pmu - generic x86 pmu
|
|
|
|
*/
|
|
|
|
struct x86_pmu {
|
|
|
|
/*
|
|
|
|
* Generic x86 PMC bits
|
|
|
|
*/
|
|
|
|
const char *name;
|
|
|
|
int version;
|
|
|
|
int (*handle_irq)(struct pt_regs *);
|
|
|
|
void (*disable_all)(void);
|
|
|
|
void (*enable_all)(int added);
|
|
|
|
void (*enable)(struct perf_event *);
|
|
|
|
void (*disable)(struct perf_event *);
|
2021-09-07 16:39:01 +00:00
|
|
|
void (*assign)(struct perf_event *event, int idx);
|
perf/x86: Ensure perf_sched_cb_{inc,dec}() is only called from pmu::{add,del}()
Currently perf_sched_cb_{inc,dec}() are called from
pmu::{start,stop}(), which has the problem that this can happen from
NMI context, this is making it hard to optimize perf_pmu_sched_task().
Furthermore, we really only need this accounting on pmu::{add,del}(),
so doing it from pmu::{start,stop}() is doing more work than we really
need.
Introduce x86_pmu::{add,del}() and wire up the LBR and PEBS.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-07-06 16:02:43 +00:00
|
|
|
void (*add)(struct perf_event *);
|
|
|
|
void (*del)(struct perf_event *);
|
2018-02-12 22:20:32 +00:00
|
|
|
void (*read)(struct perf_event *event);
|
2011-08-30 23:41:05 +00:00
|
|
|
int (*hw_config)(struct perf_event *event);
|
|
|
|
int (*schedule_events)(struct cpu_hw_events *cpuc, int n, int *assign);
|
|
|
|
unsigned eventsel;
|
|
|
|
unsigned perfctr;
|
2013-02-06 17:26:27 +00:00
|
|
|
int (*addr_offset)(int index, bool eventsel);
|
2013-02-06 17:26:28 +00:00
|
|
|
int (*rdpmc_index)(int index);
|
2011-08-30 23:41:05 +00:00
|
|
|
u64 (*event_map)(int);
|
|
|
|
int max_events;
|
|
|
|
int num_counters;
|
|
|
|
int num_counters_fixed;
|
|
|
|
int cntval_bits;
|
|
|
|
u64 cntval_mask;
|
2011-11-10 12:57:26 +00:00
|
|
|
union {
|
|
|
|
unsigned long events_maskl;
|
|
|
|
unsigned long events_mask[BITS_TO_LONGS(ARCH_PERFMON_EVENTS_COUNT)];
|
|
|
|
};
|
|
|
|
int events_mask_len;
|
2011-08-30 23:41:05 +00:00
|
|
|
int apic;
|
|
|
|
u64 max_period;
|
|
|
|
struct event_constraint *
|
|
|
|
(*get_event_constraints)(struct cpu_hw_events *cpuc,
|
2014-11-17 19:06:56 +00:00
|
|
|
int idx,
|
2011-08-30 23:41:05 +00:00
|
|
|
struct perf_event *event);
|
|
|
|
|
|
|
|
void (*put_event_constraints)(struct cpu_hw_events *cpuc,
|
|
|
|
struct perf_event *event);
|
2014-11-17 19:06:55 +00:00
|
|
|
|
|
|
|
void (*start_scheduling)(struct cpu_hw_events *cpuc);
|
|
|
|
|
2015-05-21 08:57:32 +00:00
|
|
|
void (*commit_scheduling)(struct cpu_hw_events *cpuc, int idx, int cntr);
|
|
|
|
|
2014-11-17 19:06:55 +00:00
|
|
|
void (*stop_scheduling)(struct cpu_hw_events *cpuc);
|
|
|
|
|
2011-08-30 23:41:05 +00:00
|
|
|
struct event_constraint *event_constraints;
|
2011-12-06 13:07:15 +00:00
|
|
|
struct x86_pmu_quirk *quirks;
|
2011-08-30 23:41:05 +00:00
|
|
|
int perfctr_second_write;
|
2018-03-01 17:54:54 +00:00
|
|
|
u64 (*limit_period)(struct perf_event *event, u64 l);
|
2011-08-30 23:41:05 +00:00
|
|
|
|
2018-08-08 07:12:07 +00:00
|
|
|
/* PMI handler bits */
|
|
|
|
unsigned int late_ack :1,
|
2021-08-03 13:25:28 +00:00
|
|
|
mid_ack :1,
|
2020-11-10 15:37:51 +00:00
|
|
|
enabled_ack :1;
|
2011-11-20 22:30:47 +00:00
|
|
|
/*
|
|
|
|
* sysfs attrs
|
|
|
|
*/
|
2014-02-05 19:48:51 +00:00
|
|
|
int attr_rdpmc_broken;
|
2011-11-20 22:30:47 +00:00
|
|
|
int attr_rdpmc;
|
2012-03-15 19:09:14 +00:00
|
|
|
struct attribute **format_attrs;
|
2011-11-20 22:30:47 +00:00
|
|
|
|
2012-10-10 12:53:11 +00:00
|
|
|
ssize_t (*events_sysfs_show)(char *page, u64 config);
|
2019-05-12 15:55:13 +00:00
|
|
|
const struct attribute_group **attr_update;
|
2012-10-10 12:53:11 +00:00
|
|
|
|
2017-05-12 14:51:13 +00:00
|
|
|
unsigned long attr_freeze_on_smi;
|
|
|
|
|
2011-11-20 22:30:47 +00:00
|
|
|
/*
|
|
|
|
* CPU Hotplug hooks
|
|
|
|
*/
|
2011-08-30 23:41:05 +00:00
|
|
|
int (*cpu_prepare)(int cpu);
|
|
|
|
void (*cpu_starting)(int cpu);
|
|
|
|
void (*cpu_dying)(int cpu);
|
|
|
|
void (*cpu_dead)(int cpu);
|
2012-06-08 12:50:50 +00:00
|
|
|
|
|
|
|
void (*check_microcode)(void);
|
2014-11-05 02:55:58 +00:00
|
|
|
void (*sched_task)(struct perf_event_context *ctx,
|
|
|
|
bool sched_in);
|
2011-08-30 23:41:05 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Intel Arch Perfmon v2+
|
|
|
|
*/
|
|
|
|
u64 intel_ctrl;
|
|
|
|
union perf_capabilities intel_cap;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Intel DebugStore bits
|
|
|
|
*/
|
2019-02-04 22:23:30 +00:00
|
|
|
unsigned int bts :1,
|
|
|
|
bts_active :1,
|
|
|
|
pebs :1,
|
|
|
|
pebs_active :1,
|
|
|
|
pebs_broken :1,
|
|
|
|
pebs_prec_dist :1,
|
|
|
|
pebs_no_tlb :1,
|
perf/x86/intel: Add perf core PMU support for Sapphire Rapids
Add perf core PMU support for the Intel Sapphire Rapids server, which is
the successor of the Intel Ice Lake server. The enabling code is based
on Ice Lake, but there are several new features introduced.
The event encoding is changed and simplified, e.g., the event codes
which are below 0x90 are restricted to counters 0-3. The event codes
which above 0x90 are likely to have no restrictions. The event
constraints, extra_regs(), and hardware cache events table are changed
accordingly.
A new Precise Distribution (PDist) facility is introduced, which
further minimizes the skid when a precise event is programmed on the GP
counter 0. Enable the Precise Distribution (PDist) facility with :ppp
event. For this facility to work, the period must be initialized with a
value larger than 127. Add spr_limit_period() to apply the limit for
:ppp event.
Two new data source fields, data block & address block, are added in the
PEBS Memory Info Record for the load latency event. To enable the
feature,
- An auxiliary event has to be enabled together with the load latency
event on Sapphire Rapids. A new flag PMU_FL_MEM_LOADS_AUX is
introduced to indicate the case. A new event, mem-loads-aux, is
exposed to sysfs for the user tool.
Add a check in hw_config(). If the auxiliary event is not detected,
return an unique error -ENODATA.
- The union perf_mem_data_src is extended to support the new fields.
- Ice Lake and earlier models do not support block information, but the
fields may be set by HW on some machines. Add pebs_no_block to
explicitly indicate the previous platforms which don't support the new
block fields. Accessing the new block fields are ignored on those
platforms.
A new store Latency facility is introduced, which leverages the PEBS
facility where it can provide additional information about sampled
stores. The additional information includes the data address, memory
auxiliary info (e.g. Data Source, STLB miss) and the latency of the
store access. To enable the facility, the new event (0x02cd) has to be
programed on the GP counter 0. A new flag PERF_X86_EVENT_PEBS_STLAT is
introduced to indicate the event. The store_latency_data() is introduced
to parse the memory auxiliary info.
The layout of access latency field of PEBS Memory Info Record has been
changed. Two latency, instruction latency (bit 15:0) and cache access
latency (bit 47:32) are recorded.
- The cache access latency is similar to previous memory access latency.
For loads, the latency starts by the actual cache access until the
data is returned by the memory subsystem.
For stores, the latency starts when the demand write accesses the L1
data cache and lasts until the cacheline write is completed in the
memory subsystem.
The cache access latency is stored in low 32bits of the sample type
PERF_SAMPLE_WEIGHT_STRUCT.
- The instruction latency starts by the dispatch of the load operation
for execution and lasts until completion of the instruction it belongs
to.
Add a new flag PMU_FL_INSTR_LATENCY to indicate the instruction
latency support. The instruction latency is stored in the bit 47:32
of the sample type PERF_SAMPLE_WEIGHT_STRUCT.
Extends the PERF_METRICS MSR to feature TMA method level 2 metrics. The
lower half of the register is the TMA level 1 metrics (legacy). The
upper half is also divided into four 8-bit fields for the new level 2
metrics. Expose all eight Topdown metrics events to user space.
The full description for the SPR features can be found at Intel
Architecture Instruction Set Extensions and Future Features
Programming Reference, 319433-041.
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/1611873611-156687-5-git-send-email-kan.liang@linux.intel.com
2021-01-28 22:40:10 +00:00
|
|
|
pebs_no_isolation :1,
|
|
|
|
pebs_block :1;
|
2011-08-30 23:41:05 +00:00
|
|
|
int pebs_record_size;
|
2016-03-01 19:03:52 +00:00
|
|
|
int pebs_buffer_size;
|
perf/x86/intel: Support adaptive PEBS v4
Adaptive PEBS is a new way to report PEBS sampling information. Instead
of a fixed size record for all PEBS events it allows to configure the
PEBS record to only include the information needed. Events can then opt
in to use such an extended record, or stay with a basic record which
only contains the IP.
The major new feature is to support LBRs in PEBS record.
Besides normal LBR, this allows (much faster) large PEBS, while still
supporting callstacks through callstack LBR. So essentially a lot of
profiling can now be done without frequent interrupts, dropping the
overhead significantly.
The main requirement still is to use a period, and not use frequency
mode, because frequency mode requires reevaluating the frequency on each
overflow.
The floating point state (XMM) is also supported, which allows efficient
profiling of FP function arguments.
Introduce specific drain function to handle variable length records.
Use a new callback to parse the new record format, and also handle the
STATUS field now being at a different offset.
Add code to set up the configuration register. Since there is only a
single register, all events either get the full super set of all events,
or only the basic record.
Originally-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Cc: acme@kernel.org
Cc: jolsa@kernel.org
Link: https://lkml.kernel.org/r/20190402194509.2832-6-kan.liang@linux.intel.com
[ Renamed GPRS => GP. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-04-02 19:45:02 +00:00
|
|
|
int max_pebs_events;
|
2020-10-30 13:58:48 +00:00
|
|
|
void (*drain_pebs)(struct pt_regs *regs, struct perf_sample_data *data);
|
2011-08-30 23:41:05 +00:00
|
|
|
struct event_constraint *pebs_constraints;
|
2012-06-05 08:26:43 +00:00
|
|
|
void (*pebs_aliases)(struct perf_event *event);
|
2018-03-12 14:45:37 +00:00
|
|
|
unsigned long large_pebs_flags;
|
perf/x86/intel: Support adaptive PEBS v4
Adaptive PEBS is a new way to report PEBS sampling information. Instead
of a fixed size record for all PEBS events it allows to configure the
PEBS record to only include the information needed. Events can then opt
in to use such an extended record, or stay with a basic record which
only contains the IP.
The major new feature is to support LBRs in PEBS record.
Besides normal LBR, this allows (much faster) large PEBS, while still
supporting callstacks through callstack LBR. So essentially a lot of
profiling can now be done without frequent interrupts, dropping the
overhead significantly.
The main requirement still is to use a period, and not use frequency
mode, because frequency mode requires reevaluating the frequency on each
overflow.
The floating point state (XMM) is also supported, which allows efficient
profiling of FP function arguments.
Introduce specific drain function to handle variable length records.
Use a new callback to parse the new record format, and also handle the
STATUS field now being at a different offset.
Add code to set up the configuration register. Since there is only a
single register, all events either get the full super set of all events,
or only the basic record.
Originally-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Cc: acme@kernel.org
Cc: jolsa@kernel.org
Link: https://lkml.kernel.org/r/20190402194509.2832-6-kan.liang@linux.intel.com
[ Renamed GPRS => GP. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-04-02 19:45:02 +00:00
|
|
|
u64 rtm_abort_event;
|
2011-08-30 23:41:05 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Intel LBR
|
|
|
|
*/
|
2020-06-13 08:09:46 +00:00
|
|
|
unsigned int lbr_tos, lbr_from, lbr_to,
|
2020-07-03 12:49:18 +00:00
|
|
|
lbr_info, lbr_nr; /* LBR base regs and size */
|
2020-07-03 12:49:15 +00:00
|
|
|
union {
|
|
|
|
u64 lbr_sel_mask; /* LBR_SELECT valid bits */
|
|
|
|
u64 lbr_ctl_mask; /* LBR_CTL valid bits */
|
|
|
|
};
|
|
|
|
union {
|
|
|
|
const int *lbr_sel_map; /* lbr_select mappings */
|
|
|
|
int *lbr_ctl_map; /* LBR_CTL mappings */
|
|
|
|
};
|
2013-09-20 14:40:44 +00:00
|
|
|
bool lbr_double_abort; /* duplicated lbr aborts */
|
2016-12-09 00:14:17 +00:00
|
|
|
bool lbr_pt_coexist; /* (LBR|BTS) may coexist with PT */
|
2011-08-30 23:41:05 +00:00
|
|
|
|
2020-07-03 12:49:14 +00:00
|
|
|
/*
|
|
|
|
* Intel Architectural LBR CPUID Enumeration
|
|
|
|
*/
|
|
|
|
unsigned int lbr_depth_mask:8;
|
|
|
|
unsigned int lbr_deep_c_reset:1;
|
|
|
|
unsigned int lbr_lip:1;
|
|
|
|
unsigned int lbr_cpl:1;
|
|
|
|
unsigned int lbr_filter:1;
|
|
|
|
unsigned int lbr_call_stack:1;
|
|
|
|
unsigned int lbr_mispred:1;
|
|
|
|
unsigned int lbr_timed_lbr:1;
|
|
|
|
unsigned int lbr_br_type:1;
|
|
|
|
|
2020-07-03 12:49:08 +00:00
|
|
|
void (*lbr_reset)(void);
|
2020-07-03 12:49:09 +00:00
|
|
|
void (*lbr_read)(struct cpu_hw_events *cpuc);
|
2020-07-03 12:49:10 +00:00
|
|
|
void (*lbr_save)(void *ctx);
|
|
|
|
void (*lbr_restore)(void *ctx);
|
2020-07-03 12:49:08 +00:00
|
|
|
|
2015-01-14 12:18:20 +00:00
|
|
|
/*
|
|
|
|
* Intel PT/LBR/BTS are exclusive
|
|
|
|
*/
|
|
|
|
atomic_t lbr_exclusive[x86_lbr_exclusive_max];
|
|
|
|
|
perf/x86/intel: Generic support for hardware TopDown metrics
Intro
=====
The TopDown Microarchitecture Analysis (TMA) Method is a structured
analysis methodology to identify critical performance bottlenecks in
out-of-order processors. Current perf has supported the method.
The method works well, but there is one problem. To collect the TopDown
events, several GP counters have to be used. If a user wants to collect
other events at the same time, the multiplexing probably be triggered,
which impacts the accuracy.
To free up the scarce GP counters, the hardware TopDown metrics feature
is introduced from Ice Lake. The hardware implements an additional
"metrics" register and a new Fixed Counter 3 that measures pipeline
"slots". The TopDown events can be calculated from them instead.
Events
======
The level 1 TopDown has four metrics. There is no event-code assigned to
the TopDown metrics. Four metric events are exported as separate perf
events, which map to the internal "metrics" counter register. Those
events do not exist in hardware, but can be allocated by the scheduler.
For the event mapping, a special 0x00 event code is used, which is
reserved for fake events. The metric events start from umask 0x10.
When setting up the metric events, they point to the Fixed Counter 3.
They have to be specially handled.
- Add the update_topdown_event() callback to read the additional metrics
MSR and generate the metrics.
- Add the set_topdown_event_period() callback to initialize metrics MSR
and the fixed counter 3.
- Add a variable n_metric_event to track the number of the accepted
metrics events. The sharing between multiple users of the same metric
without multiplexing is not allowed.
- Only enable/disable the fixed counter 3 when there are no other active
TopDown events, which avoid the unnecessary writing of the fixed
control register.
- Disable the PMU when reading the metrics event. The metrics MSR and
the fixed counter 3 are read separately. The values may be modified by
an NMI.
All four metric events don't support sampling. Since they will be
handled specially for event update, a flag PERF_X86_EVENT_TOPDOWN is
introduced to indicate this case.
The slots event can support both sampling and counting.
For counting, the flag is also applied.
For sampling, it will be handled normally as other normal events.
Groups
======
The slots event is required in a Topdown group.
To avoid reading the METRICS register multiple times, the metrics and
slots value can only be updated by slots event in a group.
All active slots and metrics events will be updated one time.
Therefore, the slots event must be before any metric events in a Topdown
group.
NMI
======
The METRICS related register may be overflow. The bit 48 of the STATUS
register will be set. If so, PERF_METRICS and Fixed counter 3 are
required to be reset. The patch also update all active slots and
metrics events in the NMI handler.
The update_topdown_event() has to read two registers separately. The
values may be modified by an NMI. PMU has to be disabled before calling
the function.
RDPMC
======
RDPMC is temporarily disabled. A later patch will enable it.
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20200723171117.9918-9-kan.liang@linux.intel.com
2020-07-23 17:11:11 +00:00
|
|
|
/*
|
|
|
|
* Intel perf metrics
|
|
|
|
*/
|
2021-01-28 22:40:09 +00:00
|
|
|
int num_topdown_events;
|
perf/x86/intel: Generic support for hardware TopDown metrics
Intro
=====
The TopDown Microarchitecture Analysis (TMA) Method is a structured
analysis methodology to identify critical performance bottlenecks in
out-of-order processors. Current perf has supported the method.
The method works well, but there is one problem. To collect the TopDown
events, several GP counters have to be used. If a user wants to collect
other events at the same time, the multiplexing probably be triggered,
which impacts the accuracy.
To free up the scarce GP counters, the hardware TopDown metrics feature
is introduced from Ice Lake. The hardware implements an additional
"metrics" register and a new Fixed Counter 3 that measures pipeline
"slots". The TopDown events can be calculated from them instead.
Events
======
The level 1 TopDown has four metrics. There is no event-code assigned to
the TopDown metrics. Four metric events are exported as separate perf
events, which map to the internal "metrics" counter register. Those
events do not exist in hardware, but can be allocated by the scheduler.
For the event mapping, a special 0x00 event code is used, which is
reserved for fake events. The metric events start from umask 0x10.
When setting up the metric events, they point to the Fixed Counter 3.
They have to be specially handled.
- Add the update_topdown_event() callback to read the additional metrics
MSR and generate the metrics.
- Add the set_topdown_event_period() callback to initialize metrics MSR
and the fixed counter 3.
- Add a variable n_metric_event to track the number of the accepted
metrics events. The sharing between multiple users of the same metric
without multiplexing is not allowed.
- Only enable/disable the fixed counter 3 when there are no other active
TopDown events, which avoid the unnecessary writing of the fixed
control register.
- Disable the PMU when reading the metrics event. The metrics MSR and
the fixed counter 3 are read separately. The values may be modified by
an NMI.
All four metric events don't support sampling. Since they will be
handled specially for event update, a flag PERF_X86_EVENT_TOPDOWN is
introduced to indicate this case.
The slots event can support both sampling and counting.
For counting, the flag is also applied.
For sampling, it will be handled normally as other normal events.
Groups
======
The slots event is required in a Topdown group.
To avoid reading the METRICS register multiple times, the metrics and
slots value can only be updated by slots event in a group.
All active slots and metrics events will be updated one time.
Therefore, the slots event must be before any metric events in a Topdown
group.
NMI
======
The METRICS related register may be overflow. The bit 48 of the STATUS
register will be set. If so, PERF_METRICS and Fixed counter 3 are
required to be reset. The patch also update all active slots and
metrics events in the NMI handler.
The update_topdown_event() has to read two registers separately. The
values may be modified by an NMI. PMU has to be disabled before calling
the function.
RDPMC
======
RDPMC is temporarily disabled. A later patch will enable it.
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20200723171117.9918-9-kan.liang@linux.intel.com
2020-07-23 17:11:11 +00:00
|
|
|
u64 (*update_topdown_event)(struct perf_event *event);
|
|
|
|
int (*set_topdown_event_period)(struct perf_event *event);
|
|
|
|
|
2019-10-23 07:11:04 +00:00
|
|
|
/*
|
|
|
|
* perf task context (i.e. struct perf_event_context::task_ctx_data)
|
|
|
|
* switch helper to bridge calls from perf/core to perf/x86.
|
|
|
|
* See struct pmu::swap_task_ctx() usage for examples;
|
|
|
|
*/
|
|
|
|
void (*swap_task_ctx)(struct perf_event_context *prev,
|
|
|
|
struct perf_event_context *next);
|
|
|
|
|
2016-03-25 14:52:35 +00:00
|
|
|
/*
|
|
|
|
* AMD bits
|
|
|
|
*/
|
|
|
|
unsigned int amd_nb_constraints : 1;
|
perf/x86/amd: Add support for Large Increment per Cycle Events
Description of hardware operation
---------------------------------
The core AMD PMU has a 4-bit wide per-cycle increment for each
performance monitor counter. That works for most events, but
now with AMD Family 17h and above processors, some events can
occur more than 15 times in a cycle. Those events are called
"Large Increment per Cycle" events. In order to count these
events, two adjacent h/w PMCs get their count signals merged
to form 8 bits per cycle total. In addition, the PERF_CTR count
registers are merged to be able to count up to 64 bits.
Normally, events like instructions retired, get programmed on a single
counter like so:
PERF_CTL0 (MSR 0xc0010200) 0x000000000053ff0c # event 0x0c, umask 0xff
PERF_CTR0 (MSR 0xc0010201) 0x0000800000000001 # r/w 48-bit count
The next counter at MSRs 0xc0010202-3 remains unused, or can be used
independently to count something else.
When counting Large Increment per Cycle events, such as FLOPs,
however, we now have to reserve the next counter and program the
PERF_CTL (config) register with the Merge event (0xFFF), like so:
PERF_CTL0 (msr 0xc0010200) 0x000000000053ff03 # FLOPs event, umask 0xff
PERF_CTR0 (msr 0xc0010201) 0x0000800000000001 # rd 64-bit cnt, wr lo 48b
PERF_CTL1 (msr 0xc0010202) 0x0000000f004000ff # Merge event, enable bit
PERF_CTR1 (msr 0xc0010203) 0x0000000000000000 # wr hi 16-bits count
The count is widened from the normal 48-bits to 64 bits by having the
second counter carry the higher 16 bits of the count in its lower 16
bits of its counter register.
The odd counter, e.g., PERF_CTL1, is programmed with the enabled Merge
event before the even counter, PERF_CTL0.
The Large Increment feature is available starting with Family 17h.
For more details, search any Family 17h PPR for the "Large Increment
per Cycle Events" section, e.g., section 2.1.15.3 on p. 173 in this
version:
https://www.amd.com/system/files/TechDocs/56176_ppr_Family_17h_Model_71h_B0_pub_Rev_3.06.zip
Description of software operation
---------------------------------
The following steps are taken in order to support reserving and
enabling the extra counter for Large Increment per Cycle events:
1. In the main x86 scheduler, we reduce the number of available
counters by the number of Large Increment per Cycle events being
scheduled, tracked by a new cpuc variable 'n_pair' and a new
amd_put_event_constraints_f17h(). This improves the counter
scheduler success rate.
2. In perf_assign_events(), if a counter is assigned to a Large
Increment event, we increment the current counter variable, so the
counter used for the Merge event is removed from assignment
consideration by upcoming event assignments.
3. In find_counter(), if a counter has been found for the Large
Increment event, we set the next counter as used, to prevent other
events from using it.
4. We perform steps 2 & 3 also in the x86 scheduler fastpath, i.e.,
we add Merge event accounting to the existing used_mask logic.
5. Finally, we add on the programming of Merge event to the
neighbouring PMC counters in the counter enable/disable{_all}
code paths.
Currently, software does not support a single PMU with mixed 48- and
64-bit counting, so Large increment event counts are limited to 48
bits. In set_period, we zero-out the upper 16 bits of the count, so
the hardware doesn't copy them to the even counter's higher bits.
Simple invocation example showing counting 8 FLOPs per 256-bit/%ymm
vaddps instruction executed in a loop 100 million times:
perf stat -e cpu/fp_ret_sse_avx_ops.all/,cpu/instructions/ <workload>
Performance counter stats for '<workload>':
800,000,000 cpu/fp_ret_sse_avx_ops.all/u
300,042,101 cpu/instructions/u
Prior to this patch, the reported SSE/AVX FLOPs retired count would
be wrong.
[peterz: lots of renames and edits to the code]
Signed-off-by: Kim Phillips <kim.phillips@amd.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
2019-11-14 18:37:20 +00:00
|
|
|
u64 perf_ctr_pair_en;
|
2016-03-25 14:52:35 +00:00
|
|
|
|
2011-08-30 23:41:05 +00:00
|
|
|
/*
|
|
|
|
* Extra registers for events
|
|
|
|
*/
|
|
|
|
struct extra_reg *extra_regs;
|
2014-11-17 19:06:53 +00:00
|
|
|
unsigned int flags;
|
2011-10-05 12:01:21 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Intel host/guest support (KVM)
|
|
|
|
*/
|
|
|
|
struct perf_guest_switch_msr *(*guest_get_msrs)(int *nr);
|
2019-02-04 12:35:32 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Check period value for PERF_EVENT_IOC_PERIOD ioctl.
|
|
|
|
*/
|
|
|
|
int (*check_period) (struct perf_event *event, u64 period);
|
perf/x86/intel: Support PEBS output to PT
If PEBS declares ability to output its data to Intel PT stream, use the
aux_output attribute bit to enable PEBS data output to PT. This requires
a PT event to be present and scheduled in the same context. Unlike the
DS area, the kernel does not extract PEBS records from the PT stream to
generate corresponding records in the perf stream, because that would
require real time in-kernel PT decoding, which is not feasible. The PMI,
however, can still be used.
The output setting is per-CPU, so all PEBS events must be either writing
to PT or to the DS area, therefore, in case of conflict, the conflicting
event will fail to schedule, allowing the rotation logic to alternate
between the PEBS->PT and PEBS->DS events.
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: kan.liang@linux.intel.com
Link: https://lkml.kernel.org/r/20190806084606.4021-3-alexander.shishkin@linux.intel.com
2019-08-06 08:46:01 +00:00
|
|
|
|
|
|
|
int (*aux_output_match) (struct perf_event *event);
|
perf/x86/intel: Hybrid PMU support for perf capabilities
Some platforms, e.g. Alder Lake, have hybrid architecture. Although most
PMU capabilities are the same, there are still some unique PMU
capabilities for different hybrid PMUs. Perf should register a dedicated
pmu for each hybrid PMU.
Add a new struct x86_hybrid_pmu, which saves the dedicated pmu and
capabilities for each hybrid PMU.
The architecture MSR, MSR_IA32_PERF_CAPABILITIES, only indicates the
architecture features which are available on all hybrid PMUs. The
architecture features are stored in the global x86_pmu.intel_cap.
For Alder Lake, the model-specific features are perf metrics and
PEBS-via-PT. The corresponding bits of the global x86_pmu.intel_cap
should be 0 for these two features. Perf should not use the global
intel_cap to check the features on a hybrid system.
Add a dedicated intel_cap in the x86_hybrid_pmu to store the
model-specific capabilities. Use the dedicated intel_cap to replace
the global intel_cap for thse two features. The dedicated intel_cap
will be set in the following "Add Alder Lake Hybrid support" patch.
Add is_hybrid() to distinguish a hybrid system. ADL may have an
alternative configuration. With that configuration, the
X86_FEATURE_HYBRID_CPU is not set. Perf cannot rely on the feature bit.
Add a new static_key_false, perf_is_hybrid, to indicate a hybrid system.
It will be assigned in the following "Add Alder Lake Hybrid support"
patch as well.
Suggested-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/1618237865-33448-5-git-send-email-kan.liang@linux.intel.com
2021-04-12 14:30:44 +00:00
|
|
|
|
2021-04-12 14:30:59 +00:00
|
|
|
int (*filter_match)(struct perf_event *event);
|
perf/x86/intel: Hybrid PMU support for perf capabilities
Some platforms, e.g. Alder Lake, have hybrid architecture. Although most
PMU capabilities are the same, there are still some unique PMU
capabilities for different hybrid PMUs. Perf should register a dedicated
pmu for each hybrid PMU.
Add a new struct x86_hybrid_pmu, which saves the dedicated pmu and
capabilities for each hybrid PMU.
The architecture MSR, MSR_IA32_PERF_CAPABILITIES, only indicates the
architecture features which are available on all hybrid PMUs. The
architecture features are stored in the global x86_pmu.intel_cap.
For Alder Lake, the model-specific features are perf metrics and
PEBS-via-PT. The corresponding bits of the global x86_pmu.intel_cap
should be 0 for these two features. Perf should not use the global
intel_cap to check the features on a hybrid system.
Add a dedicated intel_cap in the x86_hybrid_pmu to store the
model-specific capabilities. Use the dedicated intel_cap to replace
the global intel_cap for thse two features. The dedicated intel_cap
will be set in the following "Add Alder Lake Hybrid support" patch.
Add is_hybrid() to distinguish a hybrid system. ADL may have an
alternative configuration. With that configuration, the
X86_FEATURE_HYBRID_CPU is not set. Perf cannot rely on the feature bit.
Add a new static_key_false, perf_is_hybrid, to indicate a hybrid system.
It will be assigned in the following "Add Alder Lake Hybrid support"
patch as well.
Suggested-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/1618237865-33448-5-git-send-email-kan.liang@linux.intel.com
2021-04-12 14:30:44 +00:00
|
|
|
/*
|
|
|
|
* Hybrid support
|
|
|
|
*
|
|
|
|
* Most PMU capabilities are the same among different hybrid PMUs.
|
|
|
|
* The global x86_pmu saves the architecture capabilities, which
|
|
|
|
* are available for all PMUs. The hybrid_pmu only includes the
|
|
|
|
* unique capabilities.
|
|
|
|
*/
|
2021-04-12 14:30:46 +00:00
|
|
|
int num_hybrid_pmus;
|
perf/x86/intel: Hybrid PMU support for perf capabilities
Some platforms, e.g. Alder Lake, have hybrid architecture. Although most
PMU capabilities are the same, there are still some unique PMU
capabilities for different hybrid PMUs. Perf should register a dedicated
pmu for each hybrid PMU.
Add a new struct x86_hybrid_pmu, which saves the dedicated pmu and
capabilities for each hybrid PMU.
The architecture MSR, MSR_IA32_PERF_CAPABILITIES, only indicates the
architecture features which are available on all hybrid PMUs. The
architecture features are stored in the global x86_pmu.intel_cap.
For Alder Lake, the model-specific features are perf metrics and
PEBS-via-PT. The corresponding bits of the global x86_pmu.intel_cap
should be 0 for these two features. Perf should not use the global
intel_cap to check the features on a hybrid system.
Add a dedicated intel_cap in the x86_hybrid_pmu to store the
model-specific capabilities. Use the dedicated intel_cap to replace
the global intel_cap for thse two features. The dedicated intel_cap
will be set in the following "Add Alder Lake Hybrid support" patch.
Add is_hybrid() to distinguish a hybrid system. ADL may have an
alternative configuration. With that configuration, the
X86_FEATURE_HYBRID_CPU is not set. Perf cannot rely on the feature bit.
Add a new static_key_false, perf_is_hybrid, to indicate a hybrid system.
It will be assigned in the following "Add Alder Lake Hybrid support"
patch as well.
Suggested-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/1618237865-33448-5-git-send-email-kan.liang@linux.intel.com
2021-04-12 14:30:44 +00:00
|
|
|
struct x86_hybrid_pmu *hybrid_pmu;
|
perf/x86: Register hybrid PMUs
Different hybrid PMUs have different PMU capabilities and events. Perf
should registers a dedicated PMU for each of them.
To check the X86 event, perf has to go through all possible hybrid pmus.
All the hybrid PMUs are registered at boot time. Before the
registration, add intel_pmu_check_hybrid_pmus() to check and update the
counters information, the event constraints, the extra registers and the
unique capabilities for each hybrid PMUs.
Postpone the display of the PMU information and HW check to
CPU_STARTING, because the boot CPU is the only online CPU in the
init_hw_perf_events(). Perf doesn't know the availability of the other
PMUs. Perf should display the PMU information only if the counters of
the PMU are available.
One type of CPUs may be all offline. For this case, users can still
observe the PMU in /sys/devices, but its CPU mask is 0.
All hybrid PMUs have capability PERF_PMU_CAP_HETEROGENEOUS_CPUS.
The PMU name for hybrid PMUs will be "cpu_XXX", which will be assigned
later in a separated patch.
The PMU type id for the core PMU is still PERF_TYPE_RAW. For the other
hybrid PMUs, the PMU type id is not hard code.
The event->cpu must be compatitable with the supported CPUs of the PMU.
Add a check in the x86_pmu_event_init().
The events in a group must be from the same type of hybrid PMU.
The fake cpuc used in the validation must be from the supported CPU of
the event->pmu.
Perf may not retrieve a valid core type from get_this_hybrid_cpu_type().
For example, ADL may have an alternative configuration. With that
configuration, Perf cannot retrieve the core type from the CPUID leaf
0x1a. Add a platform specific get_hybrid_cpu_type(). If the generic way
fails, invoke the platform specific get_hybrid_cpu_type().
Suggested-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/1618237865-33448-17-git-send-email-kan.liang@linux.intel.com
2021-04-12 14:30:56 +00:00
|
|
|
u8 (*get_hybrid_cpu_type) (void);
|
2011-08-30 23:41:05 +00:00
|
|
|
};
|
|
|
|
|
perf/x86/intel/lbr: Factor out a new struct for generic optimization
To reduce the overhead of a context switch with LBR enabled, some
generic optimizations were introduced, e.g. avoiding restore LBR if no
one else touched them. The generic optimizations can also be used by
Architecture LBR later. Currently, the fields for the generic
optimizations are part of structure x86_perf_task_context, which will be
deprecated by Architecture LBR. A new structure should be introduced
for the common fields of generic optimization, which can be shared
between Architecture LBR and model-specific LBR.
Both 'valid_lbrs' and 'tos' are also used by the generic optimizations,
but they are not moved into the new structure, because Architecture LBR
is stack-like. The 'valid_lbrs' which records the index of the valid LBR
is not required anymore. The TOS MSR will be removed.
LBR registers may be cleared in the deep Cstate. If so, the generic
optimizations should not be applied. Perf has to unconditionally
restore the LBR registers. A generic function is required to detect the
reset due to the deep Cstate. lbr_is_reset_in_cstate() is introduced.
Currently, for the model-specific LBR, the TOS MSR is used to detect the
reset. There will be another method introduced for Architecture LBR
later.
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/1593780569-62993-6-git-send-email-kan.liang@linux.intel.com
2020-07-03 12:49:11 +00:00
|
|
|
struct x86_perf_task_context_opt {
|
|
|
|
int lbr_callstack_users;
|
|
|
|
int lbr_stack_state;
|
|
|
|
int log_id;
|
|
|
|
};
|
|
|
|
|
2014-11-05 02:56:03 +00:00
|
|
|
struct x86_perf_task_context {
|
2020-06-13 08:09:50 +00:00
|
|
|
u64 lbr_sel;
|
2015-10-20 18:46:33 +00:00
|
|
|
int tos;
|
perf/x86/intel/lbr: Fix incomplete LBR call stack
LBR has a limited stack size. If a task has a deeper call stack than
LBR's stack size, only the overflowed part is reported. A complete call
stack may not be reconstructed by perf tool.
Current code doesn't access all LBR registers. It only read the ones
below the TOS. The LBR registers above the TOS will be discarded
unconditionally.
When a CALL is captured, the TOS is incremented by 1 , modulo max LBR
stack size. The LBR HW only records the call stack information to the
register which the TOS points to. It will not touch other LBR
registers. So the registers above the TOS probably still store the valid
call stack information for an overflowed call stack, which need to be
reported.
To retrieve complete call stack information, we need to start from TOS,
read all LBR registers until an invalid entry is detected.
0s can be used to detect the invalid entry, because:
- When a RET is captured, the HW zeros the LBR register which TOS points
to, then decreases the TOS.
- The LBR registers are reset to 0 when adding a new LBR event or
scheduling an existing LBR event.
- A taken branch at IP 0 is not expected
The context switch code is also modified to save/restore all valid LBR
registers. Furthermore, the LBR registers, which don't have valid call
stack information, need to be reset in restore, because they may be
polluted while swapped out.
Here is a small test program, tchain_deep.
Its call stack is deeper than 32.
noinline void f33(void)
{
int i;
for (i = 0; i < 10000000;) {
if (i%2)
i++;
else
i++;
}
}
noinline void f32(void)
{
f33();
}
noinline void f31(void)
{
f32();
}
... ...
noinline void f1(void)
{
f2();
}
int main()
{
f1();
}
Here is the test result on SKX. The max stack size of SKX is 32.
Without the patch:
$ perf record -e cycles --call-graph lbr -- ./tchain_deep
$ perf report --stdio
#
# Children Self Command Shared Object Symbol
# ........ ........ ........... ................ .................
#
100.00% 99.99% tchain_deep tchain_deep [.] f33
|
--99.99%--f30
f31
f32
f33
With the patch:
$ perf record -e cycles --call-graph lbr -- ./tchain_deep
$ perf report --stdio
# Children Self Command Shared Object Symbol
# ........ ........ ........... ................ ..................
#
99.99% 0.00% tchain_deep tchain_deep [.] f1
|
---f1
f2
f3
f4
f5
f6
f7
f8
f9
f10
f11
f12
f13
f14
f15
f16
f17
f18
f19
f20
f21
f22
f23
f24
f25
f26
f27
f28
f29
f30
f31
f32
f33
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Stephane Eranian <eranian@google.com>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: acme@kernel.org
Cc: eranian@google.com
Link: https://lore.kernel.org/lkml/1528213126-4312-1-git-send-email-kan.liang@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-06-05 15:38:45 +00:00
|
|
|
int valid_lbrs;
|
perf/x86/intel/lbr: Factor out a new struct for generic optimization
To reduce the overhead of a context switch with LBR enabled, some
generic optimizations were introduced, e.g. avoiding restore LBR if no
one else touched them. The generic optimizations can also be used by
Architecture LBR later. Currently, the fields for the generic
optimizations are part of structure x86_perf_task_context, which will be
deprecated by Architecture LBR. A new structure should be introduced
for the common fields of generic optimization, which can be shared
between Architecture LBR and model-specific LBR.
Both 'valid_lbrs' and 'tos' are also used by the generic optimizations,
but they are not moved into the new structure, because Architecture LBR
is stack-like. The 'valid_lbrs' which records the index of the valid LBR
is not required anymore. The TOS MSR will be removed.
LBR registers may be cleared in the deep Cstate. If so, the generic
optimizations should not be applied. Perf has to unconditionally
restore the LBR registers. A generic function is required to detect the
reset due to the deep Cstate. lbr_is_reset_in_cstate() is introduced.
Currently, for the model-specific LBR, the TOS MSR is used to detect the
reset. There will be another method introduced for Architecture LBR
later.
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/1593780569-62993-6-git-send-email-kan.liang@linux.intel.com
2020-07-03 12:49:11 +00:00
|
|
|
struct x86_perf_task_context_opt opt;
|
2020-07-03 12:49:16 +00:00
|
|
|
struct lbr_entry lbr[MAX_LBR_ENTRIES];
|
2014-11-05 02:56:03 +00:00
|
|
|
};
|
|
|
|
|
perf/x86/intel/lbr: Support Architectural LBR
Last Branch Records (LBR) enables recording of software path history by
logging taken branches and other control flows within architectural
registers now. Intel CPUs have had model-specific LBR for quite some
time, but this evolves them into an architectural feature now.
The main improvements of Architectural LBR implemented includes:
- Linux kernel can support the LBR features without knowing the model
number of the current CPU.
- Architectural LBR capabilities can be enumerated by CPUID. The
lbr_ctl_map is based on the CPUID Enumeration.
- The possible LBR depth can be retrieved from CPUID enumeration. The
max value is written to the new MSR_ARCH_LBR_DEPTH as the number of
LBR entries.
- A new IA32_LBR_CTL MSR is introduced to enable and configure LBRs,
which replaces the IA32_DEBUGCTL[bit 0] and the LBR_SELECT MSR.
- Each LBR record or entry is still comprised of three MSRs,
IA32_LBR_x_FROM_IP, IA32_LBR_x_TO_IP and IA32_LBR_x_TO_IP.
But they become the architectural MSRs.
- Architectural LBR is stack-like now. Entry 0 is always the youngest
branch, entry 1 the next youngest... The TOS MSR has been removed.
The way to enable/disable Architectural LBR is similar to the previous
model-specific LBR. __intel_pmu_lbr_enable/disable() can be reused, but
some modifications are required, which include:
- MSR_ARCH_LBR_CTL is used to enable and configure the Architectural
LBR.
- When checking the value of the IA32_DEBUGCTL MSR, ignoring the
DEBUGCTLMSR_LBR (bit 0) for Architectural LBR, which has no meaning
and always return 0.
- The FREEZE_LBRS_ON_PMI has to be explicitly set/clear, because
MSR_IA32_DEBUGCTLMSR is not touched in __intel_pmu_lbr_disable() for
Architectural LBR.
- Only MSR_ARCH_LBR_CTL is cleared in __intel_pmu_lbr_disable() for
Architectural LBR.
Some Architectural LBR dedicated functions are implemented to
reset/read/save/restore LBR.
- For reset, writing to the ARCH_LBR_DEPTH MSR clears all Arch LBR
entries, which is a lot faster and can improve the context switch
latency.
- For read, the branch type information can be retrieved from
the MSR_ARCH_LBR_INFO_*. But it's not fully compatible due to
OTHER_BRANCH type. The software decoding is still required for the
OTHER_BRANCH case.
LBR records are stored in the age order as well. Reuse
intel_pmu_store_lbr(). Check the CPUID enumeration before accessing
the corresponding bits in LBR_INFO.
- For save/restore, applying the fast reset (writing ARCH_LBR_DEPTH).
Reading 'lbr_from' of entry 0 instead of the TOS MSR to check if the
LBR registers are reset in the deep C-state. If 'the deep C-state
reset' bit is not set in CPUID enumeration, ignoring the check.
XSAVE support for Architectural LBR will be implemented later.
The number of LBR entries cannot be hardcoded anymore, which should be
retrieved from CPUID enumeration. A new structure
x86_perf_task_context_arch_lbr is introduced for Architectural LBR.
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/1593780569-62993-15-git-send-email-kan.liang@linux.intel.com
2020-07-03 12:49:20 +00:00
|
|
|
struct x86_perf_task_context_arch_lbr {
|
|
|
|
struct x86_perf_task_context_opt opt;
|
|
|
|
struct lbr_entry entries[];
|
|
|
|
};
|
|
|
|
|
perf/x86/intel/lbr: Support XSAVES/XRSTORS for LBR context switch
In the LBR call stack mode, LBR information is used to reconstruct a
call stack. To get the complete call stack, perf has to save/restore
all LBR registers during a context switch. Due to a large number of the
LBR registers, this process causes a high CPU overhead. To reduce the
CPU overhead during a context switch, use the XSAVES/XRSTORS
instructions.
Every XSAVE area must follow a canonical format: the legacy region, an
XSAVE header and the extended region. Although the LBR information is
only kept in the extended region, a space for the legacy region and
XSAVE header is still required. Add a new dedicated structure for LBR
XSAVES support.
Before enabling XSAVES support, the size of the LBR state has to be
sanity checked, because:
- the size of the software structure is calculated from the max number
of the LBR depth, which is enumerated by the CPUID leaf for Arch LBR.
The size of the LBR state is enumerated by the CPUID leaf for XSAVE
support of Arch LBR. If the values from the two CPUID leaves are not
consistent, it may trigger a buffer overflow. For example, a hypervisor
may unconsciously set inconsistent values for the two emulated CPUID.
- unlike other state components, the size of an LBR state depends on the
max number of LBRs, which may vary from generation to generation.
Expose the function xfeature_size() for the sanity check.
The LBR XSAVES support will be disabled if the size of the LBR state
enumerated by CPUID doesn't match with the size of the software
structure.
The XSAVE instruction requires 64-byte alignment for state buffers. A
new macro is added to reflect the alignment requirement. A 64-byte
aligned kmem_cache is created for architecture LBR.
Currently, the structure for each state component is maintained in
fpu/types.h. The structure for the new LBR state component should be
maintained in the same place. Move structure lbr_entry to fpu/types.h as
well for broader sharing.
Add dedicated lbr_save/lbr_restore functions for LBR XSAVES support,
which invokes the corresponding xstate helpers to XSAVES/XRSTORS LBR
information at the context switch when the call stack mode is enabled.
Since the XSAVES/XRSTORS instructions will be eventually invoked, the
dedicated functions is named with '_xsaves'/'_xrstors' postfix.
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Dave Hansen <dave.hansen@intel.com>
Link: https://lkml.kernel.org/r/1593780569-62993-23-git-send-email-kan.liang@linux.intel.com
2020-07-03 12:49:28 +00:00
|
|
|
/*
|
|
|
|
* Add padding to guarantee the 64-byte alignment of the state buffer.
|
|
|
|
*
|
|
|
|
* The structure is dynamically allocated. The size of the LBR state may vary
|
|
|
|
* based on the number of LBR registers.
|
|
|
|
*
|
|
|
|
* Do not put anything after the LBR state.
|
|
|
|
*/
|
|
|
|
struct x86_perf_task_context_arch_lbr_xsave {
|
|
|
|
struct x86_perf_task_context_opt opt;
|
|
|
|
|
|
|
|
union {
|
|
|
|
struct xregs_state xsave;
|
|
|
|
struct {
|
|
|
|
struct fxregs_state i387;
|
|
|
|
struct xstate_header header;
|
|
|
|
struct arch_lbr_state lbr;
|
|
|
|
} __attribute__ ((packed, aligned (XSAVE_ALIGNMENT)));
|
|
|
|
};
|
|
|
|
};
|
|
|
|
|
2011-12-06 13:07:15 +00:00
|
|
|
#define x86_add_quirk(func_) \
|
|
|
|
do { \
|
|
|
|
static struct x86_pmu_quirk __quirk __initdata = { \
|
|
|
|
.func = func_, \
|
|
|
|
}; \
|
|
|
|
__quirk.next = x86_pmu.quirks; \
|
|
|
|
x86_pmu.quirks = &__quirk; \
|
|
|
|
} while (0)
|
|
|
|
|
2014-11-17 19:06:53 +00:00
|
|
|
/*
|
|
|
|
* x86_pmu flags
|
|
|
|
*/
|
|
|
|
#define PMU_FL_NO_HT_SHARING 0x1 /* no hyper-threading resource sharing */
|
|
|
|
#define PMU_FL_HAS_RSP_1 0x2 /* has 2 equivalent offcore_rsp regs */
|
2014-11-17 19:06:57 +00:00
|
|
|
#define PMU_FL_EXCL_CNTRS 0x4 /* has exclusive counter requirements */
|
2014-11-17 19:07:04 +00:00
|
|
|
#define PMU_FL_EXCL_ENABLED 0x8 /* exclusive counter active */
|
2018-03-09 02:15:39 +00:00
|
|
|
#define PMU_FL_PEBS_ALL 0x10 /* all events are valid PEBS events */
|
2019-03-05 21:23:18 +00:00
|
|
|
#define PMU_FL_TFA 0x20 /* deal with TSX force abort */
|
2019-11-14 18:37:19 +00:00
|
|
|
#define PMU_FL_PAIR 0x40 /* merge counters for large incr. events */
|
perf/x86/intel: Add perf core PMU support for Sapphire Rapids
Add perf core PMU support for the Intel Sapphire Rapids server, which is
the successor of the Intel Ice Lake server. The enabling code is based
on Ice Lake, but there are several new features introduced.
The event encoding is changed and simplified, e.g., the event codes
which are below 0x90 are restricted to counters 0-3. The event codes
which above 0x90 are likely to have no restrictions. The event
constraints, extra_regs(), and hardware cache events table are changed
accordingly.
A new Precise Distribution (PDist) facility is introduced, which
further minimizes the skid when a precise event is programmed on the GP
counter 0. Enable the Precise Distribution (PDist) facility with :ppp
event. For this facility to work, the period must be initialized with a
value larger than 127. Add spr_limit_period() to apply the limit for
:ppp event.
Two new data source fields, data block & address block, are added in the
PEBS Memory Info Record for the load latency event. To enable the
feature,
- An auxiliary event has to be enabled together with the load latency
event on Sapphire Rapids. A new flag PMU_FL_MEM_LOADS_AUX is
introduced to indicate the case. A new event, mem-loads-aux, is
exposed to sysfs for the user tool.
Add a check in hw_config(). If the auxiliary event is not detected,
return an unique error -ENODATA.
- The union perf_mem_data_src is extended to support the new fields.
- Ice Lake and earlier models do not support block information, but the
fields may be set by HW on some machines. Add pebs_no_block to
explicitly indicate the previous platforms which don't support the new
block fields. Accessing the new block fields are ignored on those
platforms.
A new store Latency facility is introduced, which leverages the PEBS
facility where it can provide additional information about sampled
stores. The additional information includes the data address, memory
auxiliary info (e.g. Data Source, STLB miss) and the latency of the
store access. To enable the facility, the new event (0x02cd) has to be
programed on the GP counter 0. A new flag PERF_X86_EVENT_PEBS_STLAT is
introduced to indicate the event. The store_latency_data() is introduced
to parse the memory auxiliary info.
The layout of access latency field of PEBS Memory Info Record has been
changed. Two latency, instruction latency (bit 15:0) and cache access
latency (bit 47:32) are recorded.
- The cache access latency is similar to previous memory access latency.
For loads, the latency starts by the actual cache access until the
data is returned by the memory subsystem.
For stores, the latency starts when the demand write accesses the L1
data cache and lasts until the cacheline write is completed in the
memory subsystem.
The cache access latency is stored in low 32bits of the sample type
PERF_SAMPLE_WEIGHT_STRUCT.
- The instruction latency starts by the dispatch of the load operation
for execution and lasts until completion of the instruction it belongs
to.
Add a new flag PMU_FL_INSTR_LATENCY to indicate the instruction
latency support. The instruction latency is stored in the bit 47:32
of the sample type PERF_SAMPLE_WEIGHT_STRUCT.
Extends the PERF_METRICS MSR to feature TMA method level 2 metrics. The
lower half of the register is the TMA level 1 metrics (legacy). The
upper half is also divided into four 8-bit fields for the new level 2
metrics. Expose all eight Topdown metrics events to user space.
The full description for the SPR features can be found at Intel
Architecture Instruction Set Extensions and Future Features
Programming Reference, 319433-041.
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/1611873611-156687-5-git-send-email-kan.liang@linux.intel.com
2021-01-28 22:40:10 +00:00
|
|
|
#define PMU_FL_INSTR_LATENCY 0x80 /* Support Instruction Latency in PEBS Memory Info Record */
|
|
|
|
#define PMU_FL_MEM_LOADS_AUX 0x100 /* Require an auxiliary event for the complete memory info */
|
2011-08-30 23:41:05 +00:00
|
|
|
|
2013-01-24 15:10:26 +00:00
|
|
|
#define EVENT_VAR(_id) event_attr_##_id
|
|
|
|
#define EVENT_PTR(_id) &event_attr_##_id.attr.attr
|
|
|
|
|
|
|
|
#define EVENT_ATTR(_name, _id) \
|
|
|
|
static struct perf_pmu_events_attr EVENT_VAR(_id) = { \
|
|
|
|
.attr = __ATTR(_name, 0444, events_sysfs_show, NULL), \
|
|
|
|
.id = PERF_COUNT_HW_##_id, \
|
|
|
|
.event_str = NULL, \
|
|
|
|
};
|
|
|
|
|
|
|
|
#define EVENT_ATTR_STR(_name, v, str) \
|
|
|
|
static struct perf_pmu_events_attr event_attr_##v = { \
|
|
|
|
.attr = __ATTR(_name, 0444, events_sysfs_show, NULL), \
|
|
|
|
.id = 0, \
|
|
|
|
.event_str = str, \
|
|
|
|
};
|
|
|
|
|
2016-05-20 00:09:56 +00:00
|
|
|
#define EVENT_ATTR_STR_HT(_name, v, noht, ht) \
|
|
|
|
static struct perf_pmu_events_ht_attr event_attr_##v = { \
|
|
|
|
.attr = __ATTR(_name, 0444, events_ht_sysfs_show, NULL),\
|
|
|
|
.id = 0, \
|
|
|
|
.event_str_noht = noht, \
|
|
|
|
.event_str_ht = ht, \
|
|
|
|
}
|
|
|
|
|
perf/x86: Add structures for the attributes of Hybrid PMUs
Hybrid PMUs have different events and formats. In theory, Hybrid PMU
specific attributes should be maintained in the dedicated struct
x86_hybrid_pmu, but it wastes space because the events and formats are
similar among Hybrid PMUs.
To reduce duplication, all hybrid PMUs will share a group of attributes
in the following patch. To distinguish an attribute from different
Hybrid PMUs, a PMU aware attribute structure is introduced. A PMU type
is required for the attribute structure. The type is internal usage. It
is not visible in the sysfs API.
Hybrid PMUs may support the same event name, but with different event
encoding, e.g., the mem-loads event on an Atom PMU has different event
encoding from a Core PMU. It brings issue if two attributes are
created for them. Current sysfs_update_group finds an attribute by
searching the attr name (aka event name). If two attributes have the
same event name, the first attribute will be replaced.
To address the issue, only one attribute is created for the event. The
event_str is extended and stores event encodings from all Hybrid PMUs.
Each event encoding is divided by ";". The order of the event encodings
must follow the order of the hybrid PMU index. The event_str is internal
usage as well. When a user wants to show the attribute of a Hybrid PMU,
only the corresponding part of the string is displayed.
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Link: https://lkml.kernel.org/r/1618237865-33448-18-git-send-email-kan.liang@linux.intel.com
2021-04-12 14:30:57 +00:00
|
|
|
#define EVENT_ATTR_STR_HYBRID(_name, v, str, _pmu) \
|
|
|
|
static struct perf_pmu_events_hybrid_attr event_attr_##v = { \
|
|
|
|
.attr = __ATTR(_name, 0444, events_hybrid_sysfs_show, NULL),\
|
|
|
|
.id = 0, \
|
|
|
|
.event_str = str, \
|
|
|
|
.pmu_type = _pmu, \
|
|
|
|
}
|
|
|
|
|
|
|
|
#define FORMAT_HYBRID_PTR(_id) (&format_attr_hybrid_##_id.attr.attr)
|
|
|
|
|
|
|
|
#define FORMAT_ATTR_HYBRID(_name, _pmu) \
|
|
|
|
static struct perf_pmu_format_hybrid_attr format_attr_hybrid_##_name = {\
|
|
|
|
.attr = __ATTR_RO(_name), \
|
|
|
|
.pmu_type = _pmu, \
|
|
|
|
}
|
|
|
|
|
2021-04-12 14:30:43 +00:00
|
|
|
struct pmu *x86_get_pmu(unsigned int cpu);
|
2011-08-30 23:41:05 +00:00
|
|
|
extern struct x86_pmu x86_pmu __read_mostly;
|
|
|
|
|
2020-07-03 12:49:12 +00:00
|
|
|
static __always_inline struct x86_perf_task_context_opt *task_context_opt(void *ctx)
|
|
|
|
{
|
perf/x86/intel/lbr: Support Architectural LBR
Last Branch Records (LBR) enables recording of software path history by
logging taken branches and other control flows within architectural
registers now. Intel CPUs have had model-specific LBR for quite some
time, but this evolves them into an architectural feature now.
The main improvements of Architectural LBR implemented includes:
- Linux kernel can support the LBR features without knowing the model
number of the current CPU.
- Architectural LBR capabilities can be enumerated by CPUID. The
lbr_ctl_map is based on the CPUID Enumeration.
- The possible LBR depth can be retrieved from CPUID enumeration. The
max value is written to the new MSR_ARCH_LBR_DEPTH as the number of
LBR entries.
- A new IA32_LBR_CTL MSR is introduced to enable and configure LBRs,
which replaces the IA32_DEBUGCTL[bit 0] and the LBR_SELECT MSR.
- Each LBR record or entry is still comprised of three MSRs,
IA32_LBR_x_FROM_IP, IA32_LBR_x_TO_IP and IA32_LBR_x_TO_IP.
But they become the architectural MSRs.
- Architectural LBR is stack-like now. Entry 0 is always the youngest
branch, entry 1 the next youngest... The TOS MSR has been removed.
The way to enable/disable Architectural LBR is similar to the previous
model-specific LBR. __intel_pmu_lbr_enable/disable() can be reused, but
some modifications are required, which include:
- MSR_ARCH_LBR_CTL is used to enable and configure the Architectural
LBR.
- When checking the value of the IA32_DEBUGCTL MSR, ignoring the
DEBUGCTLMSR_LBR (bit 0) for Architectural LBR, which has no meaning
and always return 0.
- The FREEZE_LBRS_ON_PMI has to be explicitly set/clear, because
MSR_IA32_DEBUGCTLMSR is not touched in __intel_pmu_lbr_disable() for
Architectural LBR.
- Only MSR_ARCH_LBR_CTL is cleared in __intel_pmu_lbr_disable() for
Architectural LBR.
Some Architectural LBR dedicated functions are implemented to
reset/read/save/restore LBR.
- For reset, writing to the ARCH_LBR_DEPTH MSR clears all Arch LBR
entries, which is a lot faster and can improve the context switch
latency.
- For read, the branch type information can be retrieved from
the MSR_ARCH_LBR_INFO_*. But it's not fully compatible due to
OTHER_BRANCH type. The software decoding is still required for the
OTHER_BRANCH case.
LBR records are stored in the age order as well. Reuse
intel_pmu_store_lbr(). Check the CPUID enumeration before accessing
the corresponding bits in LBR_INFO.
- For save/restore, applying the fast reset (writing ARCH_LBR_DEPTH).
Reading 'lbr_from' of entry 0 instead of the TOS MSR to check if the
LBR registers are reset in the deep C-state. If 'the deep C-state
reset' bit is not set in CPUID enumeration, ignoring the check.
XSAVE support for Architectural LBR will be implemented later.
The number of LBR entries cannot be hardcoded anymore, which should be
retrieved from CPUID enumeration. A new structure
x86_perf_task_context_arch_lbr is introduced for Architectural LBR.
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/1593780569-62993-15-git-send-email-kan.liang@linux.intel.com
2020-07-03 12:49:20 +00:00
|
|
|
if (static_cpu_has(X86_FEATURE_ARCH_LBR))
|
|
|
|
return &((struct x86_perf_task_context_arch_lbr *)ctx)->opt;
|
|
|
|
|
2020-07-03 12:49:12 +00:00
|
|
|
return &((struct x86_perf_task_context *)ctx)->opt;
|
|
|
|
}
|
|
|
|
|
perf/x86/intel: Add basic Haswell LBR call stack support
Haswell has a new feature that utilizes the existing LBR facility to
record call chains. To enable this feature, bits (JCC, NEAR_IND_JMP,
NEAR_REL_JMP, FAR_BRANCH, EN_CALLSTACK) in LBR_SELECT must be set to 1,
bits (NEAR_REL_CALL, NEAR-IND_CALL, NEAR_RET) must be cleared. Due to
a hardware bug of Haswell, this feature doesn't work well with
FREEZE_LBRS_ON_PMI.
When the call stack feature is enabled, the LBR stack will capture
unfiltered call data normally, but as return instructions are executed,
the last captured branch record is flushed from the on-chip registers
in a last-in first-out (LIFO) manner. Thus, branch information relative
to leaf functions will not be captured, while preserving the call stack
information of the main line execution path.
This patch defines a separate lbr_sel map for Haswell. The map contains
a new entry for the call stack feature.
Signed-off-by: Yan, Zheng <zheng.z.yan@intel.com>
Signed-off-by: Kan Liang <kan.liang@intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Cc: eranian@google.com
Cc: jolsa@redhat.com
Link: http://lkml.kernel.org/r/1415156173-10035-5-git-send-email-kan.liang@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-11-05 02:56:00 +00:00
|
|
|
static inline bool x86_pmu_has_lbr_callstack(void)
|
|
|
|
{
|
|
|
|
return x86_pmu.lbr_sel_map &&
|
|
|
|
x86_pmu.lbr_sel_map[PERF_SAMPLE_BRANCH_CALL_STACK_SHIFT] > 0;
|
|
|
|
}
|
|
|
|
|
2011-08-30 23:41:05 +00:00
|
|
|
DECLARE_PER_CPU(struct cpu_hw_events, cpu_hw_events);
|
|
|
|
|
|
|
|
int x86_perf_event_set_period(struct perf_event *event);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Generalized hw caching related hw_event table, filled
|
|
|
|
* in on a per model basis. A value of 0 means
|
|
|
|
* 'not supported', -1 means 'hw_event makes no sense on
|
|
|
|
* this CPU', any other value means the raw hw_event
|
|
|
|
* ID.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#define C(x) PERF_COUNT_HW_CACHE_##x
|
|
|
|
|
|
|
|
extern u64 __read_mostly hw_cache_event_ids
|
|
|
|
[PERF_COUNT_HW_CACHE_MAX]
|
|
|
|
[PERF_COUNT_HW_CACHE_OP_MAX]
|
|
|
|
[PERF_COUNT_HW_CACHE_RESULT_MAX];
|
|
|
|
extern u64 __read_mostly hw_cache_extra_regs
|
|
|
|
[PERF_COUNT_HW_CACHE_MAX]
|
|
|
|
[PERF_COUNT_HW_CACHE_OP_MAX]
|
|
|
|
[PERF_COUNT_HW_CACHE_RESULT_MAX];
|
|
|
|
|
|
|
|
u64 x86_perf_event_update(struct perf_event *event);
|
|
|
|
|
|
|
|
static inline unsigned int x86_pmu_config_addr(int index)
|
|
|
|
{
|
2013-02-06 17:26:27 +00:00
|
|
|
return x86_pmu.eventsel + (x86_pmu.addr_offset ?
|
|
|
|
x86_pmu.addr_offset(index, true) : index);
|
2011-08-30 23:41:05 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline unsigned int x86_pmu_event_addr(int index)
|
|
|
|
{
|
2013-02-06 17:26:27 +00:00
|
|
|
return x86_pmu.perfctr + (x86_pmu.addr_offset ?
|
|
|
|
x86_pmu.addr_offset(index, false) : index);
|
2011-08-30 23:41:05 +00:00
|
|
|
}
|
|
|
|
|
2013-02-06 17:26:28 +00:00
|
|
|
static inline int x86_pmu_rdpmc_index(int index)
|
|
|
|
{
|
|
|
|
return x86_pmu.rdpmc_index ? x86_pmu.rdpmc_index(index) : index;
|
|
|
|
}
|
|
|
|
|
2021-04-12 14:30:45 +00:00
|
|
|
bool check_hw_exists(struct pmu *pmu, int num_counters,
|
|
|
|
int num_counters_fixed);
|
|
|
|
|
2015-01-14 12:18:20 +00:00
|
|
|
int x86_add_exclusive(unsigned int what);
|
|
|
|
|
|
|
|
void x86_del_exclusive(unsigned int what);
|
|
|
|
|
2015-06-11 12:13:56 +00:00
|
|
|
int x86_reserve_hardware(void);
|
|
|
|
|
|
|
|
void x86_release_hardware(void);
|
|
|
|
|
2017-08-22 18:52:01 +00:00
|
|
|
int x86_pmu_max_precise(void);
|
|
|
|
|
2015-01-14 12:18:20 +00:00
|
|
|
void hw_perf_lbr_event_destroy(struct perf_event *event);
|
|
|
|
|
2011-08-30 23:41:05 +00:00
|
|
|
int x86_setup_perfctr(struct perf_event *event);
|
|
|
|
|
|
|
|
int x86_pmu_hw_config(struct perf_event *event);
|
|
|
|
|
|
|
|
void x86_pmu_disable_all(void);
|
|
|
|
|
perf/x86/amd: Add support for Large Increment per Cycle Events
Description of hardware operation
---------------------------------
The core AMD PMU has a 4-bit wide per-cycle increment for each
performance monitor counter. That works for most events, but
now with AMD Family 17h and above processors, some events can
occur more than 15 times in a cycle. Those events are called
"Large Increment per Cycle" events. In order to count these
events, two adjacent h/w PMCs get their count signals merged
to form 8 bits per cycle total. In addition, the PERF_CTR count
registers are merged to be able to count up to 64 bits.
Normally, events like instructions retired, get programmed on a single
counter like so:
PERF_CTL0 (MSR 0xc0010200) 0x000000000053ff0c # event 0x0c, umask 0xff
PERF_CTR0 (MSR 0xc0010201) 0x0000800000000001 # r/w 48-bit count
The next counter at MSRs 0xc0010202-3 remains unused, or can be used
independently to count something else.
When counting Large Increment per Cycle events, such as FLOPs,
however, we now have to reserve the next counter and program the
PERF_CTL (config) register with the Merge event (0xFFF), like so:
PERF_CTL0 (msr 0xc0010200) 0x000000000053ff03 # FLOPs event, umask 0xff
PERF_CTR0 (msr 0xc0010201) 0x0000800000000001 # rd 64-bit cnt, wr lo 48b
PERF_CTL1 (msr 0xc0010202) 0x0000000f004000ff # Merge event, enable bit
PERF_CTR1 (msr 0xc0010203) 0x0000000000000000 # wr hi 16-bits count
The count is widened from the normal 48-bits to 64 bits by having the
second counter carry the higher 16 bits of the count in its lower 16
bits of its counter register.
The odd counter, e.g., PERF_CTL1, is programmed with the enabled Merge
event before the even counter, PERF_CTL0.
The Large Increment feature is available starting with Family 17h.
For more details, search any Family 17h PPR for the "Large Increment
per Cycle Events" section, e.g., section 2.1.15.3 on p. 173 in this
version:
https://www.amd.com/system/files/TechDocs/56176_ppr_Family_17h_Model_71h_B0_pub_Rev_3.06.zip
Description of software operation
---------------------------------
The following steps are taken in order to support reserving and
enabling the extra counter for Large Increment per Cycle events:
1. In the main x86 scheduler, we reduce the number of available
counters by the number of Large Increment per Cycle events being
scheduled, tracked by a new cpuc variable 'n_pair' and a new
amd_put_event_constraints_f17h(). This improves the counter
scheduler success rate.
2. In perf_assign_events(), if a counter is assigned to a Large
Increment event, we increment the current counter variable, so the
counter used for the Merge event is removed from assignment
consideration by upcoming event assignments.
3. In find_counter(), if a counter has been found for the Large
Increment event, we set the next counter as used, to prevent other
events from using it.
4. We perform steps 2 & 3 also in the x86 scheduler fastpath, i.e.,
we add Merge event accounting to the existing used_mask logic.
5. Finally, we add on the programming of Merge event to the
neighbouring PMC counters in the counter enable/disable{_all}
code paths.
Currently, software does not support a single PMU with mixed 48- and
64-bit counting, so Large increment event counts are limited to 48
bits. In set_period, we zero-out the upper 16 bits of the count, so
the hardware doesn't copy them to the even counter's higher bits.
Simple invocation example showing counting 8 FLOPs per 256-bit/%ymm
vaddps instruction executed in a loop 100 million times:
perf stat -e cpu/fp_ret_sse_avx_ops.all/,cpu/instructions/ <workload>
Performance counter stats for '<workload>':
800,000,000 cpu/fp_ret_sse_avx_ops.all/u
300,042,101 cpu/instructions/u
Prior to this patch, the reported SSE/AVX FLOPs retired count would
be wrong.
[peterz: lots of renames and edits to the code]
Signed-off-by: Kim Phillips <kim.phillips@amd.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
2019-11-14 18:37:20 +00:00
|
|
|
static inline bool is_counter_pair(struct hw_perf_event *hwc)
|
|
|
|
{
|
|
|
|
return hwc->flags & PERF_X86_EVENT_PAIR;
|
|
|
|
}
|
|
|
|
|
2011-08-30 23:41:05 +00:00
|
|
|
static inline void __x86_pmu_enable_event(struct hw_perf_event *hwc,
|
|
|
|
u64 enable_mask)
|
|
|
|
{
|
2012-02-29 13:57:32 +00:00
|
|
|
u64 disable_mask = __this_cpu_read(cpu_hw_events.perf_ctr_virt_mask);
|
|
|
|
|
2011-08-30 23:41:05 +00:00
|
|
|
if (hwc->extra_reg.reg)
|
|
|
|
wrmsrl(hwc->extra_reg.reg, hwc->extra_reg.config);
|
perf/x86/amd: Add support for Large Increment per Cycle Events
Description of hardware operation
---------------------------------
The core AMD PMU has a 4-bit wide per-cycle increment for each
performance monitor counter. That works for most events, but
now with AMD Family 17h and above processors, some events can
occur more than 15 times in a cycle. Those events are called
"Large Increment per Cycle" events. In order to count these
events, two adjacent h/w PMCs get their count signals merged
to form 8 bits per cycle total. In addition, the PERF_CTR count
registers are merged to be able to count up to 64 bits.
Normally, events like instructions retired, get programmed on a single
counter like so:
PERF_CTL0 (MSR 0xc0010200) 0x000000000053ff0c # event 0x0c, umask 0xff
PERF_CTR0 (MSR 0xc0010201) 0x0000800000000001 # r/w 48-bit count
The next counter at MSRs 0xc0010202-3 remains unused, or can be used
independently to count something else.
When counting Large Increment per Cycle events, such as FLOPs,
however, we now have to reserve the next counter and program the
PERF_CTL (config) register with the Merge event (0xFFF), like so:
PERF_CTL0 (msr 0xc0010200) 0x000000000053ff03 # FLOPs event, umask 0xff
PERF_CTR0 (msr 0xc0010201) 0x0000800000000001 # rd 64-bit cnt, wr lo 48b
PERF_CTL1 (msr 0xc0010202) 0x0000000f004000ff # Merge event, enable bit
PERF_CTR1 (msr 0xc0010203) 0x0000000000000000 # wr hi 16-bits count
The count is widened from the normal 48-bits to 64 bits by having the
second counter carry the higher 16 bits of the count in its lower 16
bits of its counter register.
The odd counter, e.g., PERF_CTL1, is programmed with the enabled Merge
event before the even counter, PERF_CTL0.
The Large Increment feature is available starting with Family 17h.
For more details, search any Family 17h PPR for the "Large Increment
per Cycle Events" section, e.g., section 2.1.15.3 on p. 173 in this
version:
https://www.amd.com/system/files/TechDocs/56176_ppr_Family_17h_Model_71h_B0_pub_Rev_3.06.zip
Description of software operation
---------------------------------
The following steps are taken in order to support reserving and
enabling the extra counter for Large Increment per Cycle events:
1. In the main x86 scheduler, we reduce the number of available
counters by the number of Large Increment per Cycle events being
scheduled, tracked by a new cpuc variable 'n_pair' and a new
amd_put_event_constraints_f17h(). This improves the counter
scheduler success rate.
2. In perf_assign_events(), if a counter is assigned to a Large
Increment event, we increment the current counter variable, so the
counter used for the Merge event is removed from assignment
consideration by upcoming event assignments.
3. In find_counter(), if a counter has been found for the Large
Increment event, we set the next counter as used, to prevent other
events from using it.
4. We perform steps 2 & 3 also in the x86 scheduler fastpath, i.e.,
we add Merge event accounting to the existing used_mask logic.
5. Finally, we add on the programming of Merge event to the
neighbouring PMC counters in the counter enable/disable{_all}
code paths.
Currently, software does not support a single PMU with mixed 48- and
64-bit counting, so Large increment event counts are limited to 48
bits. In set_period, we zero-out the upper 16 bits of the count, so
the hardware doesn't copy them to the even counter's higher bits.
Simple invocation example showing counting 8 FLOPs per 256-bit/%ymm
vaddps instruction executed in a loop 100 million times:
perf stat -e cpu/fp_ret_sse_avx_ops.all/,cpu/instructions/ <workload>
Performance counter stats for '<workload>':
800,000,000 cpu/fp_ret_sse_avx_ops.all/u
300,042,101 cpu/instructions/u
Prior to this patch, the reported SSE/AVX FLOPs retired count would
be wrong.
[peterz: lots of renames and edits to the code]
Signed-off-by: Kim Phillips <kim.phillips@amd.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
2019-11-14 18:37:20 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Add enabled Merge event on next counter
|
|
|
|
* if large increment event being enabled on this counter
|
|
|
|
*/
|
|
|
|
if (is_counter_pair(hwc))
|
|
|
|
wrmsrl(x86_pmu_config_addr(hwc->idx + 1), x86_pmu.perf_ctr_pair_en);
|
|
|
|
|
2012-02-29 13:57:32 +00:00
|
|
|
wrmsrl(hwc->config_base, (hwc->config | enable_mask) & ~disable_mask);
|
2011-08-30 23:41:05 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void x86_pmu_enable_all(int added);
|
|
|
|
|
2015-05-21 08:57:13 +00:00
|
|
|
int perf_assign_events(struct event_constraint **constraints, int n,
|
2015-05-21 08:57:17 +00:00
|
|
|
int wmin, int wmax, int gpmax, int *assign);
|
2011-08-30 23:41:05 +00:00
|
|
|
int x86_schedule_events(struct cpu_hw_events *cpuc, int n, int *assign);
|
|
|
|
|
|
|
|
void x86_pmu_stop(struct perf_event *event, int flags);
|
|
|
|
|
|
|
|
static inline void x86_pmu_disable_event(struct perf_event *event)
|
|
|
|
{
|
2021-08-02 07:08:50 +00:00
|
|
|
u64 disable_mask = __this_cpu_read(cpu_hw_events.perf_ctr_virt_mask);
|
2011-08-30 23:41:05 +00:00
|
|
|
struct hw_perf_event *hwc = &event->hw;
|
|
|
|
|
2021-08-02 07:08:50 +00:00
|
|
|
wrmsrl(hwc->config_base, hwc->config & ~disable_mask);
|
perf/x86/amd: Add support for Large Increment per Cycle Events
Description of hardware operation
---------------------------------
The core AMD PMU has a 4-bit wide per-cycle increment for each
performance monitor counter. That works for most events, but
now with AMD Family 17h and above processors, some events can
occur more than 15 times in a cycle. Those events are called
"Large Increment per Cycle" events. In order to count these
events, two adjacent h/w PMCs get their count signals merged
to form 8 bits per cycle total. In addition, the PERF_CTR count
registers are merged to be able to count up to 64 bits.
Normally, events like instructions retired, get programmed on a single
counter like so:
PERF_CTL0 (MSR 0xc0010200) 0x000000000053ff0c # event 0x0c, umask 0xff
PERF_CTR0 (MSR 0xc0010201) 0x0000800000000001 # r/w 48-bit count
The next counter at MSRs 0xc0010202-3 remains unused, or can be used
independently to count something else.
When counting Large Increment per Cycle events, such as FLOPs,
however, we now have to reserve the next counter and program the
PERF_CTL (config) register with the Merge event (0xFFF), like so:
PERF_CTL0 (msr 0xc0010200) 0x000000000053ff03 # FLOPs event, umask 0xff
PERF_CTR0 (msr 0xc0010201) 0x0000800000000001 # rd 64-bit cnt, wr lo 48b
PERF_CTL1 (msr 0xc0010202) 0x0000000f004000ff # Merge event, enable bit
PERF_CTR1 (msr 0xc0010203) 0x0000000000000000 # wr hi 16-bits count
The count is widened from the normal 48-bits to 64 bits by having the
second counter carry the higher 16 bits of the count in its lower 16
bits of its counter register.
The odd counter, e.g., PERF_CTL1, is programmed with the enabled Merge
event before the even counter, PERF_CTL0.
The Large Increment feature is available starting with Family 17h.
For more details, search any Family 17h PPR for the "Large Increment
per Cycle Events" section, e.g., section 2.1.15.3 on p. 173 in this
version:
https://www.amd.com/system/files/TechDocs/56176_ppr_Family_17h_Model_71h_B0_pub_Rev_3.06.zip
Description of software operation
---------------------------------
The following steps are taken in order to support reserving and
enabling the extra counter for Large Increment per Cycle events:
1. In the main x86 scheduler, we reduce the number of available
counters by the number of Large Increment per Cycle events being
scheduled, tracked by a new cpuc variable 'n_pair' and a new
amd_put_event_constraints_f17h(). This improves the counter
scheduler success rate.
2. In perf_assign_events(), if a counter is assigned to a Large
Increment event, we increment the current counter variable, so the
counter used for the Merge event is removed from assignment
consideration by upcoming event assignments.
3. In find_counter(), if a counter has been found for the Large
Increment event, we set the next counter as used, to prevent other
events from using it.
4. We perform steps 2 & 3 also in the x86 scheduler fastpath, i.e.,
we add Merge event accounting to the existing used_mask logic.
5. Finally, we add on the programming of Merge event to the
neighbouring PMC counters in the counter enable/disable{_all}
code paths.
Currently, software does not support a single PMU with mixed 48- and
64-bit counting, so Large increment event counts are limited to 48
bits. In set_period, we zero-out the upper 16 bits of the count, so
the hardware doesn't copy them to the even counter's higher bits.
Simple invocation example showing counting 8 FLOPs per 256-bit/%ymm
vaddps instruction executed in a loop 100 million times:
perf stat -e cpu/fp_ret_sse_avx_ops.all/,cpu/instructions/ <workload>
Performance counter stats for '<workload>':
800,000,000 cpu/fp_ret_sse_avx_ops.all/u
300,042,101 cpu/instructions/u
Prior to this patch, the reported SSE/AVX FLOPs retired count would
be wrong.
[peterz: lots of renames and edits to the code]
Signed-off-by: Kim Phillips <kim.phillips@amd.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
2019-11-14 18:37:20 +00:00
|
|
|
|
|
|
|
if (is_counter_pair(hwc))
|
|
|
|
wrmsrl(x86_pmu_config_addr(hwc->idx + 1), 0);
|
2011-08-30 23:41:05 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void x86_pmu_enable_event(struct perf_event *event);
|
|
|
|
|
|
|
|
int x86_pmu_handle_irq(struct pt_regs *regs);
|
|
|
|
|
2021-04-12 14:30:55 +00:00
|
|
|
void x86_pmu_show_pmu_cap(int num_counters, int num_counters_fixed,
|
|
|
|
u64 intel_ctrl);
|
|
|
|
|
perf/x86: Register hybrid PMUs
Different hybrid PMUs have different PMU capabilities and events. Perf
should registers a dedicated PMU for each of them.
To check the X86 event, perf has to go through all possible hybrid pmus.
All the hybrid PMUs are registered at boot time. Before the
registration, add intel_pmu_check_hybrid_pmus() to check and update the
counters information, the event constraints, the extra registers and the
unique capabilities for each hybrid PMUs.
Postpone the display of the PMU information and HW check to
CPU_STARTING, because the boot CPU is the only online CPU in the
init_hw_perf_events(). Perf doesn't know the availability of the other
PMUs. Perf should display the PMU information only if the counters of
the PMU are available.
One type of CPUs may be all offline. For this case, users can still
observe the PMU in /sys/devices, but its CPU mask is 0.
All hybrid PMUs have capability PERF_PMU_CAP_HETEROGENEOUS_CPUS.
The PMU name for hybrid PMUs will be "cpu_XXX", which will be assigned
later in a separated patch.
The PMU type id for the core PMU is still PERF_TYPE_RAW. For the other
hybrid PMUs, the PMU type id is not hard code.
The event->cpu must be compatitable with the supported CPUs of the PMU.
Add a check in the x86_pmu_event_init().
The events in a group must be from the same type of hybrid PMU.
The fake cpuc used in the validation must be from the supported CPU of
the event->pmu.
Perf may not retrieve a valid core type from get_this_hybrid_cpu_type().
For example, ADL may have an alternative configuration. With that
configuration, Perf cannot retrieve the core type from the CPUID leaf
0x1a. Add a platform specific get_hybrid_cpu_type(). If the generic way
fails, invoke the platform specific get_hybrid_cpu_type().
Suggested-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/1618237865-33448-17-git-send-email-kan.liang@linux.intel.com
2021-04-12 14:30:56 +00:00
|
|
|
void x86_pmu_update_cpu_context(struct pmu *pmu, int cpu);
|
|
|
|
|
2011-08-30 23:41:05 +00:00
|
|
|
extern struct event_constraint emptyconstraint;
|
|
|
|
|
|
|
|
extern struct event_constraint unconstrained;
|
|
|
|
|
2012-02-09 22:20:58 +00:00
|
|
|
static inline bool kernel_ip(unsigned long ip)
|
|
|
|
{
|
|
|
|
#ifdef CONFIG_X86_32
|
|
|
|
return ip > PAGE_OFFSET;
|
|
|
|
#else
|
|
|
|
return (long)ip < 0;
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2012-07-10 07:42:15 +00:00
|
|
|
/*
|
|
|
|
* Not all PMUs provide the right context information to place the reported IP
|
|
|
|
* into full context. Specifically segment registers are typically not
|
|
|
|
* supplied.
|
|
|
|
*
|
|
|
|
* Assuming the address is a linear address (it is for IBS), we fake the CS and
|
|
|
|
* vm86 mode using the known zero-based code segment and 'fix up' the registers
|
|
|
|
* to reflect this.
|
|
|
|
*
|
|
|
|
* Intel PEBS/LBR appear to typically provide the effective address, nothing
|
|
|
|
* much we can do about that but pray and treat it like a linear address.
|
|
|
|
*/
|
|
|
|
static inline void set_linear_ip(struct pt_regs *regs, unsigned long ip)
|
|
|
|
{
|
|
|
|
regs->cs = kernel_ip(ip) ? __KERNEL_CS : __USER_CS;
|
|
|
|
if (regs->flags & X86_VM_MASK)
|
|
|
|
regs->flags ^= (PERF_EFLAGS_VM | X86_VM_MASK);
|
|
|
|
regs->ip = ip;
|
|
|
|
}
|
|
|
|
|
2012-10-10 12:53:14 +00:00
|
|
|
ssize_t x86_event_sysfs_show(char *page, u64 config, u64 event);
|
2012-10-10 12:53:15 +00:00
|
|
|
ssize_t intel_event_sysfs_show(char *page, u64 config);
|
2012-10-10 12:53:13 +00:00
|
|
|
|
2016-03-25 03:18:25 +00:00
|
|
|
ssize_t events_sysfs_show(struct device *dev, struct device_attribute *attr,
|
|
|
|
char *page);
|
2016-05-20 00:09:56 +00:00
|
|
|
ssize_t events_ht_sysfs_show(struct device *dev, struct device_attribute *attr,
|
|
|
|
char *page);
|
perf/x86: Add structures for the attributes of Hybrid PMUs
Hybrid PMUs have different events and formats. In theory, Hybrid PMU
specific attributes should be maintained in the dedicated struct
x86_hybrid_pmu, but it wastes space because the events and formats are
similar among Hybrid PMUs.
To reduce duplication, all hybrid PMUs will share a group of attributes
in the following patch. To distinguish an attribute from different
Hybrid PMUs, a PMU aware attribute structure is introduced. A PMU type
is required for the attribute structure. The type is internal usage. It
is not visible in the sysfs API.
Hybrid PMUs may support the same event name, but with different event
encoding, e.g., the mem-loads event on an Atom PMU has different event
encoding from a Core PMU. It brings issue if two attributes are
created for them. Current sysfs_update_group finds an attribute by
searching the attr name (aka event name). If two attributes have the
same event name, the first attribute will be replaced.
To address the issue, only one attribute is created for the event. The
event_str is extended and stores event encodings from all Hybrid PMUs.
Each event encoding is divided by ";". The order of the event encodings
must follow the order of the hybrid PMU index. The event_str is internal
usage as well. When a user wants to show the attribute of a Hybrid PMU,
only the corresponding part of the string is displayed.
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Link: https://lkml.kernel.org/r/1618237865-33448-18-git-send-email-kan.liang@linux.intel.com
2021-04-12 14:30:57 +00:00
|
|
|
ssize_t events_hybrid_sysfs_show(struct device *dev,
|
|
|
|
struct device_attribute *attr,
|
|
|
|
char *page);
|
2016-03-25 03:18:25 +00:00
|
|
|
|
2021-04-12 14:30:45 +00:00
|
|
|
static inline bool fixed_counter_disabled(int i, struct pmu *pmu)
|
2021-01-28 22:40:11 +00:00
|
|
|
{
|
2021-04-12 14:30:45 +00:00
|
|
|
u64 intel_ctrl = hybrid(pmu, intel_ctrl);
|
|
|
|
|
|
|
|
return !(intel_ctrl >> (i + INTEL_PMC_IDX_FIXED));
|
2021-01-28 22:40:11 +00:00
|
|
|
}
|
|
|
|
|
2011-08-30 23:41:05 +00:00
|
|
|
#ifdef CONFIG_CPU_SUP_AMD
|
|
|
|
|
|
|
|
int amd_pmu_init(void);
|
|
|
|
|
|
|
|
#else /* CONFIG_CPU_SUP_AMD */
|
|
|
|
|
|
|
|
static inline int amd_pmu_init(void)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif /* CONFIG_CPU_SUP_AMD */
|
|
|
|
|
perf/x86/intel: Support PEBS output to PT
If PEBS declares ability to output its data to Intel PT stream, use the
aux_output attribute bit to enable PEBS data output to PT. This requires
a PT event to be present and scheduled in the same context. Unlike the
DS area, the kernel does not extract PEBS records from the PT stream to
generate corresponding records in the perf stream, because that would
require real time in-kernel PT decoding, which is not feasible. The PMI,
however, can still be used.
The output setting is per-CPU, so all PEBS events must be either writing
to PT or to the DS area, therefore, in case of conflict, the conflicting
event will fail to schedule, allowing the rotation logic to alternate
between the PEBS->PT and PEBS->DS events.
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: kan.liang@linux.intel.com
Link: https://lkml.kernel.org/r/20190806084606.4021-3-alexander.shishkin@linux.intel.com
2019-08-06 08:46:01 +00:00
|
|
|
static inline int is_pebs_pt(struct perf_event *event)
|
|
|
|
{
|
|
|
|
return !!(event->hw.flags & PERF_X86_EVENT_PEBS_VIA_PT);
|
|
|
|
}
|
|
|
|
|
2011-08-30 23:41:05 +00:00
|
|
|
#ifdef CONFIG_CPU_SUP_INTEL
|
|
|
|
|
2019-02-04 12:35:32 +00:00
|
|
|
static inline bool intel_pmu_has_bts_period(struct perf_event *event, u64 period)
|
2015-01-14 12:18:20 +00:00
|
|
|
{
|
2018-11-21 10:16:11 +00:00
|
|
|
struct hw_perf_event *hwc = &event->hw;
|
|
|
|
unsigned int hw_event, bts_event;
|
|
|
|
|
|
|
|
if (event->attr.freq)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
hw_event = hwc->config & INTEL_ARCH_EVENT_MASK;
|
|
|
|
bts_event = x86_pmu.event_map(PERF_COUNT_HW_BRANCH_INSTRUCTIONS);
|
2015-01-14 12:18:20 +00:00
|
|
|
|
2019-02-04 12:35:32 +00:00
|
|
|
return hw_event == bts_event && period == 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline bool intel_pmu_has_bts(struct perf_event *event)
|
|
|
|
{
|
|
|
|
struct hw_perf_event *hwc = &event->hw;
|
|
|
|
|
|
|
|
return intel_pmu_has_bts_period(event, hwc->sample_period);
|
2015-01-14 12:18:20 +00:00
|
|
|
}
|
|
|
|
|
2021-09-10 18:33:50 +00:00
|
|
|
static __always_inline void __intel_pmu_pebs_disable_all(void)
|
|
|
|
{
|
|
|
|
wrmsrl(MSR_IA32_PEBS_ENABLE, 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
static __always_inline void __intel_pmu_arch_lbr_disable(void)
|
|
|
|
{
|
|
|
|
wrmsrl(MSR_ARCH_LBR_CTL, 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
static __always_inline void __intel_pmu_lbr_disable(void)
|
|
|
|
{
|
|
|
|
u64 debugctl;
|
|
|
|
|
|
|
|
rdmsrl(MSR_IA32_DEBUGCTLMSR, debugctl);
|
|
|
|
debugctl &= ~(DEBUGCTLMSR_LBR | DEBUGCTLMSR_FREEZE_LBRS_ON_PMI);
|
|
|
|
wrmsrl(MSR_IA32_DEBUGCTLMSR, debugctl);
|
|
|
|
}
|
|
|
|
|
2011-08-30 23:41:05 +00:00
|
|
|
int intel_pmu_save_and_restart(struct perf_event *event);
|
|
|
|
|
|
|
|
struct event_constraint *
|
2014-11-17 19:06:56 +00:00
|
|
|
x86_get_event_constraints(struct cpu_hw_events *cpuc, int idx,
|
|
|
|
struct perf_event *event);
|
2011-08-30 23:41:05 +00:00
|
|
|
|
2019-03-05 21:23:15 +00:00
|
|
|
extern int intel_cpuc_prepare(struct cpu_hw_events *cpuc, int cpu);
|
|
|
|
extern void intel_cpuc_finish(struct cpu_hw_events *cpuc);
|
2011-08-30 23:41:05 +00:00
|
|
|
|
|
|
|
int intel_pmu_init(void);
|
|
|
|
|
|
|
|
void init_debug_store_on_cpu(int cpu);
|
|
|
|
|
|
|
|
void fini_debug_store_on_cpu(int cpu);
|
|
|
|
|
|
|
|
void release_ds_buffers(void);
|
|
|
|
|
|
|
|
void reserve_ds_buffers(void);
|
|
|
|
|
2020-07-03 12:49:29 +00:00
|
|
|
void release_lbr_buffers(void);
|
|
|
|
|
2021-04-30 05:22:47 +00:00
|
|
|
void reserve_lbr_buffers(void);
|
|
|
|
|
2011-08-30 23:41:05 +00:00
|
|
|
extern struct event_constraint bts_constraint;
|
2020-06-13 08:09:49 +00:00
|
|
|
extern struct event_constraint vlbr_constraint;
|
2011-08-30 23:41:05 +00:00
|
|
|
|
|
|
|
void intel_pmu_enable_bts(u64 config);
|
|
|
|
|
|
|
|
void intel_pmu_disable_bts(void);
|
|
|
|
|
|
|
|
int intel_pmu_drain_bts_buffer(void);
|
|
|
|
|
|
|
|
extern struct event_constraint intel_core2_pebs_event_constraints[];
|
|
|
|
|
|
|
|
extern struct event_constraint intel_atom_pebs_event_constraints[];
|
|
|
|
|
2013-07-18 09:02:24 +00:00
|
|
|
extern struct event_constraint intel_slm_pebs_event_constraints[];
|
|
|
|
|
2016-04-15 07:42:47 +00:00
|
|
|
extern struct event_constraint intel_glm_pebs_event_constraints[];
|
|
|
|
|
2017-07-12 13:44:23 +00:00
|
|
|
extern struct event_constraint intel_glp_pebs_event_constraints[];
|
|
|
|
|
2021-04-12 14:31:00 +00:00
|
|
|
extern struct event_constraint intel_grt_pebs_event_constraints[];
|
|
|
|
|
2011-08-30 23:41:05 +00:00
|
|
|
extern struct event_constraint intel_nehalem_pebs_event_constraints[];
|
|
|
|
|
|
|
|
extern struct event_constraint intel_westmere_pebs_event_constraints[];
|
|
|
|
|
|
|
|
extern struct event_constraint intel_snb_pebs_event_constraints[];
|
|
|
|
|
2012-09-10 23:07:01 +00:00
|
|
|
extern struct event_constraint intel_ivb_pebs_event_constraints[];
|
|
|
|
|
2013-06-18 00:36:49 +00:00
|
|
|
extern struct event_constraint intel_hsw_pebs_event_constraints[];
|
|
|
|
|
2016-03-03 19:50:42 +00:00
|
|
|
extern struct event_constraint intel_bdw_pebs_event_constraints[];
|
|
|
|
|
2015-05-10 19:22:44 +00:00
|
|
|
extern struct event_constraint intel_skl_pebs_event_constraints[];
|
|
|
|
|
2019-04-02 19:45:05 +00:00
|
|
|
extern struct event_constraint intel_icl_pebs_event_constraints[];
|
|
|
|
|
perf/x86/intel: Add perf core PMU support for Sapphire Rapids
Add perf core PMU support for the Intel Sapphire Rapids server, which is
the successor of the Intel Ice Lake server. The enabling code is based
on Ice Lake, but there are several new features introduced.
The event encoding is changed and simplified, e.g., the event codes
which are below 0x90 are restricted to counters 0-3. The event codes
which above 0x90 are likely to have no restrictions. The event
constraints, extra_regs(), and hardware cache events table are changed
accordingly.
A new Precise Distribution (PDist) facility is introduced, which
further minimizes the skid when a precise event is programmed on the GP
counter 0. Enable the Precise Distribution (PDist) facility with :ppp
event. For this facility to work, the period must be initialized with a
value larger than 127. Add spr_limit_period() to apply the limit for
:ppp event.
Two new data source fields, data block & address block, are added in the
PEBS Memory Info Record for the load latency event. To enable the
feature,
- An auxiliary event has to be enabled together with the load latency
event on Sapphire Rapids. A new flag PMU_FL_MEM_LOADS_AUX is
introduced to indicate the case. A new event, mem-loads-aux, is
exposed to sysfs for the user tool.
Add a check in hw_config(). If the auxiliary event is not detected,
return an unique error -ENODATA.
- The union perf_mem_data_src is extended to support the new fields.
- Ice Lake and earlier models do not support block information, but the
fields may be set by HW on some machines. Add pebs_no_block to
explicitly indicate the previous platforms which don't support the new
block fields. Accessing the new block fields are ignored on those
platforms.
A new store Latency facility is introduced, which leverages the PEBS
facility where it can provide additional information about sampled
stores. The additional information includes the data address, memory
auxiliary info (e.g. Data Source, STLB miss) and the latency of the
store access. To enable the facility, the new event (0x02cd) has to be
programed on the GP counter 0. A new flag PERF_X86_EVENT_PEBS_STLAT is
introduced to indicate the event. The store_latency_data() is introduced
to parse the memory auxiliary info.
The layout of access latency field of PEBS Memory Info Record has been
changed. Two latency, instruction latency (bit 15:0) and cache access
latency (bit 47:32) are recorded.
- The cache access latency is similar to previous memory access latency.
For loads, the latency starts by the actual cache access until the
data is returned by the memory subsystem.
For stores, the latency starts when the demand write accesses the L1
data cache and lasts until the cacheline write is completed in the
memory subsystem.
The cache access latency is stored in low 32bits of the sample type
PERF_SAMPLE_WEIGHT_STRUCT.
- The instruction latency starts by the dispatch of the load operation
for execution and lasts until completion of the instruction it belongs
to.
Add a new flag PMU_FL_INSTR_LATENCY to indicate the instruction
latency support. The instruction latency is stored in the bit 47:32
of the sample type PERF_SAMPLE_WEIGHT_STRUCT.
Extends the PERF_METRICS MSR to feature TMA method level 2 metrics. The
lower half of the register is the TMA level 1 metrics (legacy). The
upper half is also divided into four 8-bit fields for the new level 2
metrics. Expose all eight Topdown metrics events to user space.
The full description for the SPR features can be found at Intel
Architecture Instruction Set Extensions and Future Features
Programming Reference, 319433-041.
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/1611873611-156687-5-git-send-email-kan.liang@linux.intel.com
2021-01-28 22:40:10 +00:00
|
|
|
extern struct event_constraint intel_spr_pebs_event_constraints[];
|
|
|
|
|
2011-08-30 23:41:05 +00:00
|
|
|
struct event_constraint *intel_pebs_constraints(struct perf_event *event);
|
|
|
|
|
perf/x86: Ensure perf_sched_cb_{inc,dec}() is only called from pmu::{add,del}()
Currently perf_sched_cb_{inc,dec}() are called from
pmu::{start,stop}(), which has the problem that this can happen from
NMI context, this is making it hard to optimize perf_pmu_sched_task().
Furthermore, we really only need this accounting on pmu::{add,del}(),
so doing it from pmu::{start,stop}() is doing more work than we really
need.
Introduce x86_pmu::{add,del}() and wire up the LBR and PEBS.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-07-06 16:02:43 +00:00
|
|
|
void intel_pmu_pebs_add(struct perf_event *event);
|
|
|
|
|
|
|
|
void intel_pmu_pebs_del(struct perf_event *event);
|
|
|
|
|
2011-08-30 23:41:05 +00:00
|
|
|
void intel_pmu_pebs_enable(struct perf_event *event);
|
|
|
|
|
|
|
|
void intel_pmu_pebs_disable(struct perf_event *event);
|
|
|
|
|
|
|
|
void intel_pmu_pebs_enable_all(void);
|
|
|
|
|
|
|
|
void intel_pmu_pebs_disable_all(void);
|
|
|
|
|
2015-05-06 19:33:51 +00:00
|
|
|
void intel_pmu_pebs_sched_task(struct perf_event_context *ctx, bool sched_in);
|
|
|
|
|
2018-02-12 22:20:33 +00:00
|
|
|
void intel_pmu_auto_reload_read(struct perf_event *event);
|
|
|
|
|
2020-07-03 12:49:16 +00:00
|
|
|
void intel_pmu_store_pebs_lbrs(struct lbr_entry *lbr);
|
perf/x86/intel: Support adaptive PEBS v4
Adaptive PEBS is a new way to report PEBS sampling information. Instead
of a fixed size record for all PEBS events it allows to configure the
PEBS record to only include the information needed. Events can then opt
in to use such an extended record, or stay with a basic record which
only contains the IP.
The major new feature is to support LBRs in PEBS record.
Besides normal LBR, this allows (much faster) large PEBS, while still
supporting callstacks through callstack LBR. So essentially a lot of
profiling can now be done without frequent interrupts, dropping the
overhead significantly.
The main requirement still is to use a period, and not use frequency
mode, because frequency mode requires reevaluating the frequency on each
overflow.
The floating point state (XMM) is also supported, which allows efficient
profiling of FP function arguments.
Introduce specific drain function to handle variable length records.
Use a new callback to parse the new record format, and also handle the
STATUS field now being at a different offset.
Add code to set up the configuration register. Since there is only a
single register, all events either get the full super set of all events,
or only the basic record.
Originally-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Cc: acme@kernel.org
Cc: jolsa@kernel.org
Link: https://lkml.kernel.org/r/20190402194509.2832-6-kan.liang@linux.intel.com
[ Renamed GPRS => GP. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-04-02 19:45:02 +00:00
|
|
|
|
2011-08-30 23:41:05 +00:00
|
|
|
void intel_ds_init(void);
|
|
|
|
|
2019-10-23 07:12:54 +00:00
|
|
|
void intel_pmu_lbr_swap_task_ctx(struct perf_event_context *prev,
|
|
|
|
struct perf_event_context *next);
|
|
|
|
|
2014-11-05 02:55:59 +00:00
|
|
|
void intel_pmu_lbr_sched_task(struct perf_event_context *ctx, bool sched_in);
|
|
|
|
|
2016-06-21 18:31:11 +00:00
|
|
|
u64 lbr_from_signext_quirk_wr(u64 val);
|
|
|
|
|
2011-08-30 23:41:05 +00:00
|
|
|
void intel_pmu_lbr_reset(void);
|
|
|
|
|
2020-07-03 12:49:08 +00:00
|
|
|
void intel_pmu_lbr_reset_32(void);
|
|
|
|
|
|
|
|
void intel_pmu_lbr_reset_64(void);
|
|
|
|
|
perf/x86: Ensure perf_sched_cb_{inc,dec}() is only called from pmu::{add,del}()
Currently perf_sched_cb_{inc,dec}() are called from
pmu::{start,stop}(), which has the problem that this can happen from
NMI context, this is making it hard to optimize perf_pmu_sched_task().
Furthermore, we really only need this accounting on pmu::{add,del}(),
so doing it from pmu::{start,stop}() is doing more work than we really
need.
Introduce x86_pmu::{add,del}() and wire up the LBR and PEBS.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-07-06 16:02:43 +00:00
|
|
|
void intel_pmu_lbr_add(struct perf_event *event);
|
2011-08-30 23:41:05 +00:00
|
|
|
|
perf/x86: Ensure perf_sched_cb_{inc,dec}() is only called from pmu::{add,del}()
Currently perf_sched_cb_{inc,dec}() are called from
pmu::{start,stop}(), which has the problem that this can happen from
NMI context, this is making it hard to optimize perf_pmu_sched_task().
Furthermore, we really only need this accounting on pmu::{add,del}(),
so doing it from pmu::{start,stop}() is doing more work than we really
need.
Introduce x86_pmu::{add,del}() and wire up the LBR and PEBS.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-07-06 16:02:43 +00:00
|
|
|
void intel_pmu_lbr_del(struct perf_event *event);
|
2011-08-30 23:41:05 +00:00
|
|
|
|
perf/x86/intel: Streamline LBR MSR handling in PMI
The perf PMI currently does unnecessary MSR accesses when
LBRs are enabled. We use LBR freezing, or when in callstack
mode force the LBRs to only filter on ring 3.
So there is no need to disable the LBRs explicitely in the
PMI handler.
Also we always unnecessarily rewrite LBR_SELECT in the LBR
handler, even though it can never change.
5) | /* write_msr: MSR_LBR_SELECT(1c8), value 0 */
5) | /* read_msr: MSR_IA32_DEBUGCTLMSR(1d9), value 1801 */
5) | /* write_msr: MSR_IA32_DEBUGCTLMSR(1d9), value 1801 */
5) | /* write_msr: MSR_CORE_PERF_GLOBAL_CTRL(38f), value 70000000f */
5) | /* write_msr: MSR_CORE_PERF_GLOBAL_CTRL(38f), value 0 */
5) | /* write_msr: MSR_LBR_SELECT(1c8), value 0 */
5) | /* read_msr: MSR_IA32_DEBUGCTLMSR(1d9), value 1801 */
5) | /* write_msr: MSR_IA32_DEBUGCTLMSR(1d9), value 1801 */
This patch:
- Avoids disabling already frozen LBRs unnecessarily in the PMI
- Avoids changing LBR_SELECT in the PMI
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: eranian@google.com
Link: http://lkml.kernel.org/r/1426871484-21285-1-git-send-email-andi@firstfloor.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-03-20 17:11:23 +00:00
|
|
|
void intel_pmu_lbr_enable_all(bool pmi);
|
2011-08-30 23:41:05 +00:00
|
|
|
|
|
|
|
void intel_pmu_lbr_disable_all(void);
|
|
|
|
|
|
|
|
void intel_pmu_lbr_read(void);
|
|
|
|
|
2020-07-03 12:49:09 +00:00
|
|
|
void intel_pmu_lbr_read_32(struct cpu_hw_events *cpuc);
|
|
|
|
|
|
|
|
void intel_pmu_lbr_read_64(struct cpu_hw_events *cpuc);
|
|
|
|
|
2020-07-03 12:49:10 +00:00
|
|
|
void intel_pmu_lbr_save(void *ctx);
|
|
|
|
|
|
|
|
void intel_pmu_lbr_restore(void *ctx);
|
|
|
|
|
2011-08-30 23:41:05 +00:00
|
|
|
void intel_pmu_lbr_init_core(void);
|
|
|
|
|
|
|
|
void intel_pmu_lbr_init_nhm(void);
|
|
|
|
|
|
|
|
void intel_pmu_lbr_init_atom(void);
|
|
|
|
|
2016-04-15 07:53:45 +00:00
|
|
|
void intel_pmu_lbr_init_slm(void);
|
|
|
|
|
2012-02-09 22:20:55 +00:00
|
|
|
void intel_pmu_lbr_init_snb(void);
|
|
|
|
|
perf/x86/intel: Add basic Haswell LBR call stack support
Haswell has a new feature that utilizes the existing LBR facility to
record call chains. To enable this feature, bits (JCC, NEAR_IND_JMP,
NEAR_REL_JMP, FAR_BRANCH, EN_CALLSTACK) in LBR_SELECT must be set to 1,
bits (NEAR_REL_CALL, NEAR-IND_CALL, NEAR_RET) must be cleared. Due to
a hardware bug of Haswell, this feature doesn't work well with
FREEZE_LBRS_ON_PMI.
When the call stack feature is enabled, the LBR stack will capture
unfiltered call data normally, but as return instructions are executed,
the last captured branch record is flushed from the on-chip registers
in a last-in first-out (LIFO) manner. Thus, branch information relative
to leaf functions will not be captured, while preserving the call stack
information of the main line execution path.
This patch defines a separate lbr_sel map for Haswell. The map contains
a new entry for the call stack feature.
Signed-off-by: Yan, Zheng <zheng.z.yan@intel.com>
Signed-off-by: Kan Liang <kan.liang@intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Cc: eranian@google.com
Cc: jolsa@redhat.com
Link: http://lkml.kernel.org/r/1415156173-10035-5-git-send-email-kan.liang@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-11-05 02:56:00 +00:00
|
|
|
void intel_pmu_lbr_init_hsw(void);
|
|
|
|
|
2015-05-10 19:22:44 +00:00
|
|
|
void intel_pmu_lbr_init_skl(void);
|
|
|
|
|
2015-12-07 22:28:18 +00:00
|
|
|
void intel_pmu_lbr_init_knl(void);
|
|
|
|
|
perf/x86/intel/lbr: Support Architectural LBR
Last Branch Records (LBR) enables recording of software path history by
logging taken branches and other control flows within architectural
registers now. Intel CPUs have had model-specific LBR for quite some
time, but this evolves them into an architectural feature now.
The main improvements of Architectural LBR implemented includes:
- Linux kernel can support the LBR features without knowing the model
number of the current CPU.
- Architectural LBR capabilities can be enumerated by CPUID. The
lbr_ctl_map is based on the CPUID Enumeration.
- The possible LBR depth can be retrieved from CPUID enumeration. The
max value is written to the new MSR_ARCH_LBR_DEPTH as the number of
LBR entries.
- A new IA32_LBR_CTL MSR is introduced to enable and configure LBRs,
which replaces the IA32_DEBUGCTL[bit 0] and the LBR_SELECT MSR.
- Each LBR record or entry is still comprised of three MSRs,
IA32_LBR_x_FROM_IP, IA32_LBR_x_TO_IP and IA32_LBR_x_TO_IP.
But they become the architectural MSRs.
- Architectural LBR is stack-like now. Entry 0 is always the youngest
branch, entry 1 the next youngest... The TOS MSR has been removed.
The way to enable/disable Architectural LBR is similar to the previous
model-specific LBR. __intel_pmu_lbr_enable/disable() can be reused, but
some modifications are required, which include:
- MSR_ARCH_LBR_CTL is used to enable and configure the Architectural
LBR.
- When checking the value of the IA32_DEBUGCTL MSR, ignoring the
DEBUGCTLMSR_LBR (bit 0) for Architectural LBR, which has no meaning
and always return 0.
- The FREEZE_LBRS_ON_PMI has to be explicitly set/clear, because
MSR_IA32_DEBUGCTLMSR is not touched in __intel_pmu_lbr_disable() for
Architectural LBR.
- Only MSR_ARCH_LBR_CTL is cleared in __intel_pmu_lbr_disable() for
Architectural LBR.
Some Architectural LBR dedicated functions are implemented to
reset/read/save/restore LBR.
- For reset, writing to the ARCH_LBR_DEPTH MSR clears all Arch LBR
entries, which is a lot faster and can improve the context switch
latency.
- For read, the branch type information can be retrieved from
the MSR_ARCH_LBR_INFO_*. But it's not fully compatible due to
OTHER_BRANCH type. The software decoding is still required for the
OTHER_BRANCH case.
LBR records are stored in the age order as well. Reuse
intel_pmu_store_lbr(). Check the CPUID enumeration before accessing
the corresponding bits in LBR_INFO.
- For save/restore, applying the fast reset (writing ARCH_LBR_DEPTH).
Reading 'lbr_from' of entry 0 instead of the TOS MSR to check if the
LBR registers are reset in the deep C-state. If 'the deep C-state
reset' bit is not set in CPUID enumeration, ignoring the check.
XSAVE support for Architectural LBR will be implemented later.
The number of LBR entries cannot be hardcoded anymore, which should be
retrieved from CPUID enumeration. A new structure
x86_perf_task_context_arch_lbr is introduced for Architectural LBR.
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/1593780569-62993-15-git-send-email-kan.liang@linux.intel.com
2020-07-03 12:49:20 +00:00
|
|
|
void intel_pmu_arch_lbr_init(void);
|
|
|
|
|
2016-03-01 22:25:24 +00:00
|
|
|
void intel_pmu_pebs_data_source_nhm(void);
|
|
|
|
|
2017-08-16 22:21:54 +00:00
|
|
|
void intel_pmu_pebs_data_source_skl(bool pmem);
|
|
|
|
|
2012-02-09 22:20:57 +00:00
|
|
|
int intel_pmu_setup_lbr_filter(struct perf_event *event);
|
|
|
|
|
2015-01-30 10:39:52 +00:00
|
|
|
void intel_pt_interrupt(void);
|
|
|
|
|
2015-01-30 10:40:35 +00:00
|
|
|
int intel_bts_interrupt(void);
|
|
|
|
|
|
|
|
void intel_bts_enable_local(void);
|
|
|
|
|
|
|
|
void intel_bts_disable_local(void);
|
|
|
|
|
2011-08-30 23:41:05 +00:00
|
|
|
int p4_pmu_init(void);
|
|
|
|
|
|
|
|
int p6_pmu_init(void);
|
|
|
|
|
2012-09-26 18:12:52 +00:00
|
|
|
int knc_pmu_init(void);
|
|
|
|
|
2014-11-17 19:07:04 +00:00
|
|
|
static inline int is_ht_workaround_enabled(void)
|
|
|
|
{
|
|
|
|
return !!(x86_pmu.flags & PMU_FL_EXCL_ENABLED);
|
|
|
|
}
|
2015-06-29 21:22:13 +00:00
|
|
|
|
2011-08-30 23:41:05 +00:00
|
|
|
#else /* CONFIG_CPU_SUP_INTEL */
|
|
|
|
|
|
|
|
static inline void reserve_ds_buffers(void)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void release_ds_buffers(void)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2020-07-03 12:49:29 +00:00
|
|
|
static inline void release_lbr_buffers(void)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2021-04-30 05:22:47 +00:00
|
|
|
static inline void reserve_lbr_buffers(void)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2011-08-30 23:41:05 +00:00
|
|
|
static inline int intel_pmu_init(void)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-03-15 08:14:10 +00:00
|
|
|
static inline int intel_cpuc_prepare(struct cpu_hw_events *cpuc, int cpu)
|
2019-03-05 21:23:15 +00:00
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-03-15 08:14:10 +00:00
|
|
|
static inline void intel_cpuc_finish(struct cpu_hw_events *cpuc)
|
2011-08-30 23:41:05 +00:00
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2015-05-21 08:57:17 +00:00
|
|
|
static inline int is_ht_workaround_enabled(void)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
2011-08-30 23:41:05 +00:00
|
|
|
#endif /* CONFIG_CPU_SUP_INTEL */
|
2020-04-13 03:14:29 +00:00
|
|
|
|
|
|
|
#if ((defined CONFIG_CPU_SUP_CENTAUR) || (defined CONFIG_CPU_SUP_ZHAOXIN))
|
|
|
|
int zhaoxin_pmu_init(void);
|
|
|
|
#else
|
|
|
|
static inline int zhaoxin_pmu_init(void)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
#endif /*CONFIG_CPU_SUP_CENTAUR or CONFIG_CPU_SUP_ZHAOXIN*/
|