summaryrefslogtreecommitdiff
path: root/tools/perf/pmu-events/arch/x86/silvermont/frontend.json
diff options
context:
space:
mode:
authorIan Rogers <irogers@google.com>2022-12-14 22:55:03 -0800
committerArnaldo Carvalho de Melo <acme@redhat.com>2022-12-21 14:52:41 -0300
commit1b91a994a2ac3cb374249b09bb818375267aea97 (patch)
treec298fd5dcef31c520f2e1425fcbeba693ca8253f /tools/perf/pmu-events/arch/x86/silvermont/frontend.json
parent400dd489d42faef3647d990dd67f553371ec204b (diff)
perf vendor events intel: Refresh silvermont events
Update the silvermont events using the new tooling from: https://github.com/intel/perfmon The events are unchanged but unused json values are removed. This increases consistency across the json files. Signed-off-by: Ian Rogers <irogers@google.com> Acked-by: Kan Liang <kan.liang@linux.intel.com> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Caleb Biggers <caleb.biggers@intel.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: John Garry <john.g.garry@oracle.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Perry Taylor <perry.taylor@intel.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Xing Zhengjun <zhengjun.xing@linux.intel.com> Link: https://lore.kernel.org/r/20221215065510.1621979-17-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Diffstat (limited to 'tools/perf/pmu-events/arch/x86/silvermont/frontend.json')
-rw-r--r--tools/perf/pmu-events/arch/x86/silvermont/frontend.json8
1 files changed, 0 insertions, 8 deletions
diff --git a/tools/perf/pmu-events/arch/x86/silvermont/frontend.json b/tools/perf/pmu-events/arch/x86/silvermont/frontend.json
index 43e5e48f7212..c35da10f7133 100644
--- a/tools/perf/pmu-events/arch/x86/silvermont/frontend.json
+++ b/tools/perf/pmu-events/arch/x86/silvermont/frontend.json
@@ -1,7 +1,6 @@
[
{
"BriefDescription": "Counts the number of baclears",
- "Counter": "0,1",
"EventCode": "0xE6",
"EventName": "BACLEARS.ALL",
"PublicDescription": "The BACLEARS event counts the number of times the front end is resteered, mainly when the Branch Prediction Unit cannot provide a correct prediction and this is corrected by the Branch Address Calculator at the front end. The BACLEARS.ANY event counts the number of baclears for any type of branch.",
@@ -10,7 +9,6 @@
},
{
"BriefDescription": "Counts the number of JCC baclears",
- "Counter": "0,1",
"EventCode": "0xE6",
"EventName": "BACLEARS.COND",
"PublicDescription": "The BACLEARS event counts the number of times the front end is resteered, mainly when the Branch Prediction Unit cannot provide a correct prediction and this is corrected by the Branch Address Calculator at the front end. The BACLEARS.COND event counts the number of JCC (Jump on Condtional Code) baclears.",
@@ -19,7 +17,6 @@
},
{
"BriefDescription": "Counts the number of RETURN baclears",
- "Counter": "0,1",
"EventCode": "0xE6",
"EventName": "BACLEARS.RETURN",
"PublicDescription": "The BACLEARS event counts the number of times the front end is resteered, mainly when the Branch Prediction Unit cannot provide a correct prediction and this is corrected by the Branch Address Calculator at the front end. The BACLEARS.RETURN event counts the number of RETURN baclears.",
@@ -28,7 +25,6 @@
},
{
"BriefDescription": "Counts the number of times a decode restriction reduced the decode throughput due to wrong instruction length prediction",
- "Counter": "0,1",
"EventCode": "0xE9",
"EventName": "DECODE_RESTRICTION.PREDECODE_WRONG",
"PublicDescription": "Counts the number of times a decode restriction reduced the decode throughput due to wrong instruction length prediction.",
@@ -37,7 +33,6 @@
},
{
"BriefDescription": "Instruction fetches",
- "Counter": "0,1",
"EventCode": "0x80",
"EventName": "ICACHE.ACCESSES",
"PublicDescription": "This event counts all instruction fetches, not including most uncacheable\r\nfetches.",
@@ -46,7 +41,6 @@
},
{
"BriefDescription": "Instruction fetches from Icache",
- "Counter": "0,1",
"EventCode": "0x80",
"EventName": "ICACHE.HIT",
"PublicDescription": "This event counts all instruction fetches from the instruction cache.",
@@ -55,7 +49,6 @@
},
{
"BriefDescription": "Icache miss",
- "Counter": "0,1",
"EventCode": "0x80",
"EventName": "ICACHE.MISSES",
"PublicDescription": "This event counts all instruction fetches that miss the Instruction cache or produce memory requests. This includes uncacheable fetches. An instruction fetch miss is counted only once and not once for every cycle it is outstanding.",
@@ -64,7 +57,6 @@
},
{
"BriefDescription": "Counts the number of times entered into a ucode flow in the FEC. Includes inserted flows due to front-end detected faults or assists. Speculative count.",
- "Counter": "0,1",
"EventCode": "0xE7",
"EventName": "MS_DECODED.MS_ENTRY",
"PublicDescription": "Counts the number of times the MSROM starts a flow of UOPS. It does not count every time a UOP is read from the microcode ROM. The most common case that this counts is when a micro-coded instruction is encountered by the front end of the machine. Other cases include when an instruction encounters a fault, trap, or microcode assist of any sort. The event will count MSROM startups for UOPS that are speculative, and subsequently cleared by branch mispredict or machine clear. Background: UOPS are produced by two mechanisms. Either they are generated by hardware that decodes instructions into UOPS, or they are delivered by a ROM (called the MSROM) that holds UOPS associated with a specific instruction. MSROM UOPS might also be delivered in response to some condition such as a fault or other exceptional condition. This event is an excellent mechanism for detecting instructions that require the use of MSROM instructions.",