Hi,
while packaging libpfm4 4.9.0 for Debian, Lintian again complained about
a few typos, a patch is attached.
There are also some dubious strings in
lib/events/intel_bdx_unc_cbo_events.h that I didn't fix:
'(0x1(0x182)'
'(0x (0x182)'
Andreas
From aecc34eb907e7e53a62827816f47563e936364e9 Mon Sep 17 00:00:00 2001
From: Andreas Beckmann <a.beckm...@fz-juelich.de>
Date: Wed, 10 Jan 2018 22:37:20 +0100
Subject: [PATCH] fix some typos found by Lintian
Signed-off-by: Andreas Beckmann <a.beckm...@fz-juelich.de>
---
lib/events/amd64_events_fam16h.h | 2 +-
lib/events/intel_bdx_unc_cbo_events.h | 2 +-
lib/events/intel_bdx_unc_pcu_events.h | 4 ++--
lib/events/intel_bdx_unc_qpi_events.h | 14 +++++++-------
lib/events/intel_bdx_unc_r3qpi_events.h | 2 +-
5 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/lib/events/amd64_events_fam16h.h b/lib/events/amd64_events_fam16h.h
index 2eab1dc..b92e728 100644
--- a/lib/events/amd64_events_fam16h.h
+++ b/lib/events/amd64_events_fam16h.h
@@ -675,7 +675,7 @@ static const amd64_umask_t amd64_fam16h_cache_cross_invalidates[]={
.ucode = 0x4,
},
{ .uname = "IC_INVALIDATES_DC_DIRTY",
- .udesc = "Exection of modified instruction or data too close to code",
+ .udesc = "Execution of modified instruction or data too close to code",
.ucode = 0x8,
},
{ .uname = "IC_HITS_DC_CLEAN_LINE",
diff --git a/lib/events/intel_bdx_unc_cbo_events.h b/lib/events/intel_bdx_unc_cbo_events.h
index 7aa362c..c4e075a 100644
--- a/lib/events/intel_bdx_unc_cbo_events.h
+++ b/lib/events/intel_bdx_unc_cbo_events.h
@@ -1127,7 +1127,7 @@ static intel_x86_entry_t intel_bdx_unc_c_pe[]={
},
{ .name = "UNC_C_TOR_INSERTS",
.code = 0x35,
- .desc = "Counts the number of entries successfuly inserted into the TOR that match qualifications specified by the subevent. There are a number of subevent filters but only a subset of the subevent combinations are valid. Subevents that require an opcode or NID match require the Cn_MSR_PMON_BOX_FILTER.{opc, nid} field to be set. If, for example, one wanted to count DRD Local Misses, one should select MISS_OPC_MATCH and set Cn_MSR_PMON_BOX_FILTER.opc to DRD (0x1(0x182).",
+ .desc = "Counts the number of entries successfully inserted into the TOR that match qualifications specified by the subevent. There are a number of subevent filters but only a subset of the subevent combinations are valid. Subevents that require an opcode or NID match require the Cn_MSR_PMON_BOX_FILTER.{opc, nid} field to be set. If, for example, one wanted to count DRD Local Misses, one should select MISS_OPC_MATCH and set Cn_MSR_PMON_BOX_FILTER.opc to DRD (0x1(0x182).",
.modmsk = BDX_UNC_CBO_NID_ATTRS | _SNBEP_UNC_ATTR_ISOC | _SNBEP_UNC_ATTR_NC,
.flags = INTEL_X86_NO_AUTOENCODE,
.cntmsk = 0xf,
diff --git a/lib/events/intel_bdx_unc_pcu_events.h b/lib/events/intel_bdx_unc_pcu_events.h
index 24b0bd5..0d67e09 100644
--- a/lib/events/intel_bdx_unc_pcu_events.h
+++ b/lib/events/intel_bdx_unc_pcu_events.h
@@ -316,7 +316,7 @@ static intel_x86_entry_t intel_bdx_unc_p_pe[]={
},
{ .name = "UNC_P_PROCHOT_INTERNAL_CYCLES",
.code = 0x9,
- .desc = "Counts the number of cycles that we are in Interal PROCHOT mode. This mode is triggered when a sensor on the die determines that we are too hot and must throttle to avoid damaging the chip.",
+ .desc = "Counts the number of cycles that we are in internal PROCHOT mode. This mode is triggered when a sensor on the die determines that we are too hot and must throttle to avoid damaging the chip.",
.modmsk = BDX_UNC_PCU_ATTRS,
.cntmsk = 0xf,
},
@@ -346,7 +346,7 @@ static intel_x86_entry_t intel_bdx_unc_p_pe[]={
},
{ .name = "UNC_P_UFS_TRANSITIONS_NO_CHANGE",
.code = 0x79,
- .desc = "Ring GV with same final and inital frequency",
+ .desc = "Ring GV with same final and initial frequency",
.modmsk = BDX_UNC_PCU_ATTRS,
.cntmsk = 0xf,
},
diff --git a/lib/events/intel_bdx_unc_qpi_events.h b/lib/events/intel_bdx_unc_qpi_events.h
index 18c010a..d1954e6 100644
--- a/lib/events/intel_bdx_unc_qpi_events.h
+++ b/lib/events/intel_bdx_unc_qpi_events.h
@@ -304,7 +304,7 @@ static intel_x86_entry_t intel_bdx_unc_q_pe[]={
},
{ .name = "UNC_Q_DIRECT2CORE",
.code = 0x13,
- .desc = "Counts the number of DRS packets that we attempted to do direct2core on. There are 4 mutually exlusive filters. Filter [0] can be used to get successful spawns, while [1:3] provide the different failure cases. Note that this does not count packets that are not candidates for Direct2Core. The only candidates for Direct2Core are DRS packets destined for Cbos.",
+ .desc = "Counts the number of DRS packets that we attempted to do direct2core on. There are 4 mutually exclusive filters. Filter [0] can be used to get successful spawns, while [1:3] provide the different failure cases. Note that this does not count packets that are not candidates for Direct2Core. The only candidates for Direct2Core are DRS packets destined for Cbos.",
.modmsk = BDX_UNC_QPI_ATTRS,
.cntmsk = 0xf,
.ngrp = 1,
@@ -331,7 +331,7 @@ static intel_x86_entry_t intel_bdx_unc_q_pe[]={
},
{ .name = "UNC_Q_RXL_BYPASSED",
.code = 0x9,
- .desc = "Counts the number of times that an incoming flit was able to bypass the flit buffer and pass directly across the BGF and into the Egress. This is a latency optimization, and should generally be the common case. If this value is less than the number of flits transfered, it implies that there was queueing getting onto the ring, and thus the transactions saw higher latency.",
+ .desc = "Counts the number of times that an incoming flit was able to bypass the flit buffer and pass directly across the BGF and into the Egress. This is a latency optimization, and should generally be the common case. If this value is less than the number of flits transferred, it implies that there was queueing getting onto the ring, and thus the transactions saw higher latency.",
.modmsk = BDX_UNC_QPI_ATTRS,
.cntmsk = 0xf,
},
@@ -376,7 +376,7 @@ static intel_x86_entry_t intel_bdx_unc_q_pe[]={
},
{ .name = "UNC_Q_RXL_FLITS_G1",
.code = 0x2 | (1 << 21), /* extra ev_sel_ext bit set */
- .desc = "Counts the number of flits received from the QPI Link. This is one of three groups that allow us to track flits. It includes filters for SNP, HOM, and DRS message classes. Each flit is made up of 80 bits of information (in addition to some ECC data). In full-width (L0) mode, flits are made up of four fits, each of which contains 20 bits of data (along with some additional ECC data). In half-width (L0p) mode, the fits are only 10 bits, and therefore it takes twice as many fits to transmit a flit. When one talks about QPI speed (for example, 8.0 GT/s), the transfers here refer to fits. Therefore, in L0, the system will transfer 1 flit at the rate of 1/4th the QPI speed. One can calculate the bandwidth of the link by taking: flits*80b/time. Note that this is not the same as data bandwidth. For example, when we are transfering a 64B cacheline across QPI, we will break it into 9 flits -- 1 with header information and 8 with 64 bits of actual data and an additional 16 bits of other information. To calculate data bandwidth, one should therefore do: datld therefore do: data flits * 8B / time.",
+ .desc = "Counts the number of flits received from the QPI Link. This is one of three groups that allow us to track flits. It includes filters for SNP, HOM, and DRS message classes. Each flit is made up of 80 bits of information (in addition to some ECC data). In full-width (L0) mode, flits are made up of four fits, each of which contains 20 bits of data (along with some additional ECC data). In half-width (L0p) mode, the fits are only 10 bits, and therefore it takes twice as many fits to transmit a flit. When one talks about QPI speed (for example, 8.0 GT/s), the transfers here refer to fits. Therefore, in L0, the system will transfer 1 flit at the rate of 1/4th the QPI speed. One can calculate the bandwidth of the link by taking: flits*80b/time. Note that this is not the same as data bandwidth. For example, when we are transferring a 64B cacheline across QPI, we will break it into 9 flits -- 1 with header information and 8 with 64 bits of actual data and an additional 16 bits of other information. To calculate data bandwidth, one should therefore do: datld therefore do: data flits * 8B / time.",
.modmsk = BDX_UNC_QPI_ATTRS,
.cntmsk = 0xf,
.ngrp = 1,
@@ -385,7 +385,7 @@ static intel_x86_entry_t intel_bdx_unc_q_pe[]={
},
{ .name = "UNC_Q_RXL_FLITS_G2",
.code = 0x3 | (1 << 21), /* extra ev_sel_ext bit set */
- .desc = "Counts the number of flits received from the QPI Link. This is one of three groups that allow us to track flits. It includes filters for NDR, NCB, and NCS message classes. Each flit is made up of 80 bits of information (in addition to some ECC data). In full-width (L0) mode, flits are made up of four fits, each of which contains 20 bits of data (along with some additional ECC data). In half-width (L0p) mode, the fits are only 10 bits, and therefore it takes twice as many fits to transmit a flit. When one talks about QPI speed (for example, 8.0 GT/s), the transfers here refer to fits. Therefore, in L0, the system will transfer 1 flit at the rate of 1/4th the QPI speed. One can calculate the bandwidth of the link by taking: flits*80b/time. Note that this is not the same as data bandwidth. For example, when we are transfering a 64B cacheline across QPI, we will break it into 9 flits -- 1 with header information and 8 with 64 bits of actual data and an additional 16 bits of other information. To calculate data bandwidth, one should therefore do: datld therefore do: data flits * 8B / time.",
+ .desc = "Counts the number of flits received from the QPI Link. This is one of three groups that allow us to track flits. It includes filters for NDR, NCB, and NCS message classes. Each flit is made up of 80 bits of information (in addition to some ECC data). In full-width (L0) mode, flits are made up of four fits, each of which contains 20 bits of data (along with some additional ECC data). In half-width (L0p) mode, the fits are only 10 bits, and therefore it takes twice as many fits to transmit a flit. When one talks about QPI speed (for example, 8.0 GT/s), the transfers here refer to fits. Therefore, in L0, the system will transfer 1 flit at the rate of 1/4th the QPI speed. One can calculate the bandwidth of the link by taking: flits*80b/time. Note that this is not the same as data bandwidth. For example, when we are transferring a 64B cacheline across QPI, we will break it into 9 flits -- 1 with header information and 8 with 64 bits of actual data and an additional 16 bits of other information. To calculate data bandwidth, one should therefore do: datld therefore do: data flits * 8B / time.",
.modmsk = BDX_UNC_QPI_ATTRS,
.cntmsk = 0xf,
.ngrp = 1,
@@ -538,7 +538,7 @@ static intel_x86_entry_t intel_bdx_unc_q_pe[]={
},
{ .name = "UNC_Q_TXL_FLITS_G0",
.code = 0x0,
- .desc = "Counts the number of flits transmitted across the QPI Link. It includes filters for Idle, protocol, and Data Flits. Each flit is made up of 80 bits of information (in addition to some ECC data). In full-width (L0) mode, flits are made up of four fits, each of which contains 20 bits of data (along with some additional ECC data). In half-width (L0p) mode, the fits are only 10 bits, and therefore it takes twice as many fits to transmit a flit. When one talks about QPI speed (for example, 8.0 GT/s), the transfers here refer to fits. Therefore, in L0, the system will transfer 1 flit at the rate of 1/4th the QPI speed. One can calculate the bandwidth of the link by taking: flits*80b/time. Note that this is not the same as data bandwidth. For example, when we are transfering a 64B cacheline across QPI, we will break it into 9 flits -- 1 with header information and 8 with 64 bits of actual data and an additional 16 bits of other information. To calculate data bandwidth, one should therefore do: data flits * 8B / time (for L0) or 4B instfor L0) or 4B instead of 8B for L0p.",
+ .desc = "Counts the number of flits transmitted across the QPI Link. It includes filters for Idle, protocol, and Data Flits. Each flit is made up of 80 bits of information (in addition to some ECC data). In full-width (L0) mode, flits are made up of four fits, each of which contains 20 bits of data (along with some additional ECC data). In half-width (L0p) mode, the fits are only 10 bits, and therefore it takes twice as many fits to transmit a flit. When one talks about QPI speed (for example, 8.0 GT/s), the transfers here refer to fits. Therefore, in L0, the system will transfer 1 flit at the rate of 1/4th the QPI speed. One can calculate the bandwidth of the link by taking: flits*80b/time. Note that this is not the same as data bandwidth. For example, when we are transferring a 64B cacheline across QPI, we will break it into 9 flits -- 1 with header information and 8 with 64 bits of actual data and an additional 16 bits of other information. To calculate data bandwidth, one should therefore do: data flits * 8B / time (for L0) or 4B instfor L0) or 4B instead of 8B for L0p.",
.modmsk = BDX_UNC_QPI_ATTRS,
.cntmsk = 0xf,
.ngrp = 1,
@@ -547,7 +547,7 @@ static intel_x86_entry_t intel_bdx_unc_q_pe[]={
},
{ .name = "UNC_Q_TXL_FLITS_G1",
.code = 0x0 | (1 << 21), /* extra ev_sel_ext bit set */
- .desc = "Counts the number of flits transmitted across the QPI Link. It includes filters for Idle, protocol, and Data Flits. Each flit is made up of 80 bits of information (in addition to some ECC data). In full-width (L0) mode, flits are made up of four fits, each of which contains 20 bits of data (along with some additional ECC data). In half-width (L0p) mode, the fits are only 10 bits, and therefore it takes twice as many fits to transmit a flit. When one talks about QPI speed (for example, 8.0 GT/s), the transfers here refer to fits. Therefore, in L0, the system will transfer 1 flit at the rate of 1/4th the QPI speed. One can calculate the bandwidth of the link by taking: flits*80b/time. Note that this is not the same as data bandwidth. For example, when we are transfering a 64B cacheline across QPI, we will break it into 9 flits -- 1 with header information and 8 with 64 bits of actual data and an additional 16 bits of other information. To calculate data bandwidth, one should therefore do: data flits * 8B / time (for L0) or 4B instfor L0) or 4B instead of 8B for L0p.",
+ .desc = "Counts the number of flits transmitted across the QPI Link. It includes filters for Idle, protocol, and Data Flits. Each flit is made up of 80 bits of information (in addition to some ECC data). In full-width (L0) mode, flits are made up of four fits, each of which contains 20 bits of data (along with some additional ECC data). In half-width (L0p) mode, the fits are only 10 bits, and therefore it takes twice as many fits to transmit a flit. When one talks about QPI speed (for example, 8.0 GT/s), the transfers here refer to fits. Therefore, in L0, the system will transfer 1 flit at the rate of 1/4th the QPI speed. One can calculate the bandwidth of the link by taking: flits*80b/time. Note that this is not the same as data bandwidth. For example, when we are transferring a 64B cacheline across QPI, we will break it into 9 flits -- 1 with header information and 8 with 64 bits of actual data and an additional 16 bits of other information. To calculate data bandwidth, one should therefore do: data flits * 8B / time (for L0) or 4B instfor L0) or 4B instead of 8B for L0p.",
.modmsk = BDX_UNC_QPI_ATTRS,
.cntmsk = 0xf,
.ngrp = 1,
@@ -556,7 +556,7 @@ static intel_x86_entry_t intel_bdx_unc_q_pe[]={
},
{ .name = "UNC_Q_TXL_FLITS_G2",
.code = 0x1 | (1 << 21), /* extra ev_sel_ext bit set */
- .desc = "Counts the number of flits trasmitted across the QPI Link. This is one of three groups that allow us to track flits. It includes filters for NDR, NCB, and NCS message classes. Each flit is made up of 80 bits of information (in addition to some ECC data). In full-width (L0) mode, flits are made up of four fits, each of which contains 20 bits of data (along with some additional ECC data). In half-width (L0p) mode, the fits are only 10 bits, and therefore it takes twice as many fits to transmit a flit. When one talks about QPI speed (for example, 8.0 GT/s), the transfers here refer to fits. Therefore, in L0, the system will transfer 1 flit at the rate of 1/4th the QPI speed. One can calculate the bandwidth of the link by taking: flits*80b/time. Note that this is not the same as data bandwidth. For example, when we are transfering a 64B cacheline across QPI, we will break it into 9 flits -- 1 with header information and 8 with 64 bits of actual data and an additional 16 bits of other information. To calculate data bandwidth, one should therefore do: datld therefore do: data flits * 8B / time.",
+ .desc = "Counts the number of flits trasmitted across the QPI Link. This is one of three groups that allow us to track flits. It includes filters for NDR, NCB, and NCS message classes. Each flit is made up of 80 bits of information (in addition to some ECC data). In full-width (L0) mode, flits are made up of four fits, each of which contains 20 bits of data (along with some additional ECC data). In half-width (L0p) mode, the fits are only 10 bits, and therefore it takes twice as many fits to transmit a flit. When one talks about QPI speed (for example, 8.0 GT/s), the transfers here refer to fits. Therefore, in L0, the system will transfer 1 flit at the rate of 1/4th the QPI speed. One can calculate the bandwidth of the link by taking: flits*80b/time. Note that this is not the same as data bandwidth. For example, when we are transferring a 64B cacheline across QPI, we will break it into 9 flits -- 1 with header information and 8 with 64 bits of actual data and an additional 16 bits of other information. To calculate data bandwidth, one should therefore do: datld therefore do: data flits * 8B / time.",
.modmsk = BDX_UNC_QPI_ATTRS,
.cntmsk = 0xf,
.ngrp = 1,
diff --git a/lib/events/intel_bdx_unc_r3qpi_events.h b/lib/events/intel_bdx_unc_r3qpi_events.h
index 5c0b561..29da7b5 100644
--- a/lib/events/intel_bdx_unc_r3qpi_events.h
+++ b/lib/events/intel_bdx_unc_r3qpi_events.h
@@ -732,7 +732,7 @@ static intel_x86_entry_t intel_bdx_unc_r3_pe[]={
},
{ .name = "UNC_R3_VNA_CREDITS_ACQUIRED",
.code = 0x33,
- .desc = "Number of QPI VNA Credit acquisitions. This event can be used in conjunction with the VNA In-Use Accumulator to calculate the average lifetime of a credit holder. VNA credits are used by all message classes in order to communicate across QPI. If a packet is unable to acquire credits, it will then attempt to use credts from the VN0 pool. Note that a single packet may require multiple flit buffers (i.e. when data is being transfered). Therefore, this event will increment by the number of credits acquired in each cycle. Filtering based on message class is not provided. One can count the number of packets transfered in a given message class using an qfclk event.",
+ .desc = "Number of QPI VNA Credit acquisitions. This event can be used in conjunction with the VNA In-Use Accumulator to calculate the average lifetime of a credit holder. VNA credits are used by all message classes in order to communicate across QPI. If a packet is unable to acquire credits, it will then attempt to use credts from the VN0 pool. Note that a single packet may require multiple flit buffers (i.e. when data is being transferred). Therefore, this event will increment by the number of credits acquired in each cycle. Filtering based on message class is not provided. One can count the number of packets transferred in a given message class using an qfclk event.",
.modmsk = BDX_UNC_R3QPI_ATTRS,
.cntmsk = 0x3,
.ngrp = 1,
--
2.11.0
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
