The branch main has been updated by gbe (doc committer):

URL: 
https://cgit.FreeBSD.org/src/commit/?id=f0d4c2afd65f821b8983152848f4005239ff975a

commit f0d4c2afd65f821b8983152848f4005239ff975a
Author:     Gordon Bergling <[email protected]>
AuthorDate: 2022-09-04 10:52:38 +0000
Commit:     Gordon Bergling <[email protected]>
CommitDate: 2022-09-04 10:52:38 +0000

    pmc(3): Correct some typos in event descriptions
    
    - s/occured/occurred/
    - s/the the/the/
    
    MFC after:      3 days
---
 lib/libpmc/pmu-events/arch/x86/broadwell/pipeline.json        | 4 ++--
 lib/libpmc/pmu-events/arch/x86/broadwellde/pipeline.json      | 4 ++--
 lib/libpmc/pmu-events/arch/x86/broadwellx/pipeline.json       | 4 ++--
 lib/libpmc/pmu-events/arch/x86/cascadelakex/uncore-other.json | 2 +-
 lib/libpmc/pmu-events/arch/x86/silvermont/pipeline.json       | 4 ++--
 lib/libpmc/pmu-events/arch/x86/skylakex/uncore-other.json     | 2 +-
 6 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/lib/libpmc/pmu-events/arch/x86/broadwell/pipeline.json 
b/lib/libpmc/pmu-events/arch/x86/broadwell/pipeline.json
index 18d21b94a4b9..6044773c1e9a 100644
--- a/lib/libpmc/pmu-events/arch/x86/broadwell/pipeline.json
+++ b/lib/libpmc/pmu-events/arch/x86/broadwell/pipeline.json
@@ -624,7 +624,7 @@
         "CounterHTOff": "0,1,2,3,4,5,6,7",
         "EventCode": "0x87",
         "EventName": "ILD_STALL.LCP",
-        "PublicDescription": "This event counts stalls occured due to changing 
prefix length (66, 67 or REX.W when they change the length of the decoded 
instruction). Occurrences counting is proportional to the number of prefixes in 
a 16B-line. This may result in the following penalties: three-cycle penalty for 
each LCP in a 16-byte chunk.",
+        "PublicDescription": "This event counts stalls occurred due to 
changing prefix length (66, 67 or REX.W when they change the length of the 
decoded instruction). Occurrences counting is proportional to the number of 
prefixes in a 16B-line. This may result in the following penalties: three-cycle 
penalty for each LCP in a 16-byte chunk.",
         "SampleAfterValue": "2000003",
         "UMask": "0x1"
     },
@@ -1377,4 +1377,4 @@
         "SampleAfterValue": "2000003",
         "UMask": "0x1"
     }
-]
\ No newline at end of file
+]
diff --git a/lib/libpmc/pmu-events/arch/x86/broadwellde/pipeline.json 
b/lib/libpmc/pmu-events/arch/x86/broadwellde/pipeline.json
index 7580b8af0d13..1c93482e9205 100644
--- a/lib/libpmc/pmu-events/arch/x86/broadwellde/pipeline.json
+++ b/lib/libpmc/pmu-events/arch/x86/broadwellde/pipeline.json
@@ -624,7 +624,7 @@
         "CounterHTOff": "0,1,2,3,4,5,6,7",
         "EventCode": "0x87",
         "EventName": "ILD_STALL.LCP",
-        "PublicDescription": "This event counts stalls occured due to changing 
prefix length (66, 67 or REX.W when they change the length of the decoded 
instruction). Occurrences counting is proportional to the number of prefixes in 
a 16B-line. This may result in the following penalties: three-cycle penalty for 
each LCP in a 16-byte chunk.",
+        "PublicDescription": "This event counts stalls occurred due to 
changing prefix length (66, 67 or REX.W when they change the length of the 
decoded instruction). Occurrences counting is proportional to the number of 
prefixes in a 16B-line. This may result in the following penalties: three-cycle 
penalty for each LCP in a 16-byte chunk.",
         "SampleAfterValue": "2000003",
         "UMask": "0x1"
     },
@@ -1378,4 +1378,4 @@
         "SampleAfterValue": "2000003",
         "UMask": "0x1"
     }
-]
\ No newline at end of file
+]
diff --git a/lib/libpmc/pmu-events/arch/x86/broadwellx/pipeline.json 
b/lib/libpmc/pmu-events/arch/x86/broadwellx/pipeline.json
index 18d21b94a4b9..6044773c1e9a 100644
--- a/lib/libpmc/pmu-events/arch/x86/broadwellx/pipeline.json
+++ b/lib/libpmc/pmu-events/arch/x86/broadwellx/pipeline.json
@@ -624,7 +624,7 @@
         "CounterHTOff": "0,1,2,3,4,5,6,7",
         "EventCode": "0x87",
         "EventName": "ILD_STALL.LCP",
-        "PublicDescription": "This event counts stalls occured due to changing 
prefix length (66, 67 or REX.W when they change the length of the decoded 
instruction). Occurrences counting is proportional to the number of prefixes in 
a 16B-line. This may result in the following penalties: three-cycle penalty for 
each LCP in a 16-byte chunk.",
+        "PublicDescription": "This event counts stalls occurred due to 
changing prefix length (66, 67 or REX.W when they change the length of the 
decoded instruction). Occurrences counting is proportional to the number of 
prefixes in a 16B-line. This may result in the following penalties: three-cycle 
penalty for each LCP in a 16-byte chunk.",
         "SampleAfterValue": "2000003",
         "UMask": "0x1"
     },
@@ -1377,4 +1377,4 @@
         "SampleAfterValue": "2000003",
         "UMask": "0x1"
     }
-]
\ No newline at end of file
+]
diff --git a/lib/libpmc/pmu-events/arch/x86/cascadelakex/uncore-other.json 
b/lib/libpmc/pmu-events/arch/x86/cascadelakex/uncore-other.json
index aa460d0c4851..59ab88de1b37 100644
--- a/lib/libpmc/pmu-events/arch/x86/cascadelakex/uncore-other.json
+++ b/lib/libpmc/pmu-events/arch/x86/cascadelakex/uncore-other.json
@@ -1923,7 +1923,7 @@
         "EventCode": "0x25",
         "EventName": "UNC_UPI_RxL0P_POWER_CYCLES",
         "PerPkg": "1",
-        "PublicDescription": "Counts cycles when the the receive side (Rx) of 
the Intel Ultra Path Interconnect(UPI) is in L0p power mode. L0p is a mode 
where we disable 60% of the UPI lanes, decreasing our bandwidth in order to 
save power.",
+        "PublicDescription": "Counts cycles when the receive side (Rx) of the 
Intel Ultra Path Interconnect(UPI) is in L0p power mode. L0p is a mode where we 
disable 60% of the UPI lanes, decreasing our bandwidth in order to save power.",
         "Unit": "UPI LL"
     },
     {
diff --git a/lib/libpmc/pmu-events/arch/x86/silvermont/pipeline.json 
b/lib/libpmc/pmu-events/arch/x86/silvermont/pipeline.json
index 03a4c7f26698..5cc383f87448 100644
--- a/lib/libpmc/pmu-events/arch/x86/silvermont/pipeline.json
+++ b/lib/libpmc/pmu-events/arch/x86/silvermont/pipeline.json
@@ -257,7 +257,7 @@
         "Counter": "0,1",
         "EventCode": "0xCA",
         "EventName": "NO_ALLOC_CYCLES.NOT_DELIVERED",
-        "PublicDescription": "The NO_ALLOC_CYCLES.NOT_DELIVERED event is used 
to measure front-end inefficiencies, i.e. when front-end of the machine is not 
delivering micro-ops to the back-end and the back-end is not stalled. This 
event can be used to identify if the machine is truly front-end bound.  When 
this event occurs, it is an indication that the front-end of the machine is 
operating at less than its theoretical peak performance.  Background: We can 
think of the processor pipeline as being divided into 2 broader parts: 
Front-end and Back-end. Front-end is responsible for fetching the instruction, 
decoding into micro-ops (uops) in machine understandable format and putting 
them into a micro-op queue to be consumed by back end. The back-end then takes 
these micro-ops, allocates the required resources.  When all resources are 
ready, micro-ops are executed. If the back-end is not ready to accept micro-ops 
from the front-end, then we do not want to count these as front-end bottlen
 ecks.  However, whenever we have bottlenecks in the back-end, we will have 
allocation unit stalls and eventually forcing the front-end to wait until the 
back-end is ready to receive more UOPS. This event counts the cycles only when 
back-end is requesting more uops and front-end is not able to provide them. 
Some examples of conditions that cause front-end efficiencies are: Icache 
misses, ITLB misses, and decoder restrictions that limit the the front-end 
bandwidth.",
+        "PublicDescription": "The NO_ALLOC_CYCLES.NOT_DELIVERED event is used 
to measure front-end inefficiencies, i.e. when front-end of the machine is not 
delivering micro-ops to the back-end and the back-end is not stalled. This 
event can be used to identify if the machine is truly front-end bound.  When 
this event occurs, it is an indication that the front-end of the machine is 
operating at less than its theoretical peak performance.  Background: We can 
think of the processor pipeline as being divided into 2 broader parts: 
Front-end and Back-end. Front-end is responsible for fetching the instruction, 
decoding into micro-ops (uops) in machine understandable format and putting 
them into a micro-op queue to be consumed by back end. The back-end then takes 
these micro-ops, allocates the required resources.  When all resources are 
ready, micro-ops are executed. If the back-end is not ready to accept micro-ops 
from the front-end, then we do not want to count these as front-end bottlen
 ecks.  However, whenever we have bottlenecks in the back-end, we will have 
allocation unit stalls and eventually forcing the front-end to wait until the 
back-end is ready to receive more UOPS. This event counts the cycles only when 
back-end is requesting more uops and front-end is not able to provide them. 
Some examples of conditions that cause front-end efficiencies are: Icache 
misses, ITLB misses, and decoder restrictions that limit the front-end 
bandwidth.",
         "SampleAfterValue": "200003",
         "UMask": "0x50"
     },
@@ -313,4 +313,4 @@
         "SampleAfterValue": "2000003",
         "UMask": "0x1"
     }
-]
\ No newline at end of file
+]
diff --git a/lib/libpmc/pmu-events/arch/x86/skylakex/uncore-other.json 
b/lib/libpmc/pmu-events/arch/x86/skylakex/uncore-other.json
index aa0f67613c4a..0c96e6924d62 100644
--- a/lib/libpmc/pmu-events/arch/x86/skylakex/uncore-other.json
+++ b/lib/libpmc/pmu-events/arch/x86/skylakex/uncore-other.json
@@ -1852,7 +1852,7 @@
         "EventCode": "0x25",
         "EventName": "UNC_UPI_RxL0P_POWER_CYCLES",
         "PerPkg": "1",
-        "PublicDescription": "Counts cycles when the the receive side (Rx) of 
the Intel Ultra Path Interconnect(UPI) is in L0p power mode. L0p is a mode 
where we disable 60% of the UPI lanes, decreasing our bandwidth in order to 
save power.",
+        "PublicDescription": "Counts cycles when the receive side (Rx) of the 
Intel Ultra Path Interconnect(UPI) is in L0p power mode. L0p is a mode where we 
disable 60% of the UPI lanes, decreasing our bandwidth in order to save power.",
         "Unit": "UPI LL"
     },
     {

Reply via email to