* Re: [PATCH] perf vendor events power10: Adds 24x7 nest metric events for power10 platform
From: kajoljain @ 2021-06-28 6:28 UTC (permalink / raw)
To: Paul A. Clarke
Cc: ravi.bangoria, atrajeev, rnsastry, linuxppc-dev, linux-kernel,
acme, linux-perf-users, maddy, jolsa
In-Reply-To: <20210625132151.GC142768@li-24c3614c-2adc-11b2-a85c-85f334518bdb.ibm.com>
On 6/25/21 6:51 PM, Paul A. Clarke wrote:
> On Fri, Jun 25, 2021 at 05:29:48PM +0530, Kajol Jain wrote:
>> Patch adds 24x7 nest metric events for POWER10.
>>
>> Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
>> ---
>> .../arch/powerpc/power10/nest_metrics.json | 491 ++++++++++++++++++
>> 1 file changed, 491 insertions(+)
>> create mode 100644 tools/perf/pmu-events/arch/powerpc/power10/nest_metrics.json
>>
>> diff --git a/tools/perf/pmu-events/arch/powerpc/power10/nest_metrics.json b/tools/perf/pmu-events/arch/powerpc/power10/nest_metrics.json
>> new file mode 100644
>> index 000000000000..b79046cd8b09
>> --- /dev/null
>> +++ b/tools/perf/pmu-events/arch/powerpc/power10/nest_metrics.json
>> @@ -0,0 +1,491 @@
>> +[
>> + {
>> + "MetricName": "VEC_GROUP_PUMP_RETRY_RATIO_P01",
>> + "BriefDescription": "VEC_GROUP_PUMP_RETRY_RATIO_P01",
>
> Is it possible to get better descriptions than just a restatement of the
> name, or no description at all?
>
> This comment obviously applies to almost all of the metrics herein.
Hi Paul,
Thanks for reviewing the patch. Sure I will remove description part for now.
>
>> + "MetricExpr": "(hv_24x7@PM_PB_RTY_VG_PUMP01\\,chip\\=?@ / hv_24x7@PM_PB_VG_PUMP01\\,chip\\=?@) * 100",
>> + "ScaleUnit": "1%",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "VEC_GROUP_PUMP_RETRY_RATIO_P23",
>> + "BriefDescription": "VEC_GROUP_PUMP_RETRY_RATIO_P23",
>> + "MetricExpr": "(hv_24x7@PM_PB_RTY_VG_PUMP23\\,chip\\=?@ / hv_24x7@PM_PB_VG_PUMP23\\,chip\\=?@) * 100",
>> + "ScaleUnit": "1%",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "LOCAL_NODE_PUMP_RETRY_RATIO_P01",
>> + "BriefDescription": "LOCAL_NODE_PUMP_RETRY_RATIO_P01",
>> + "MetricExpr": "(hv_24x7@PM_PB_RTY_LNS_PUMP01\\,chip\\=?@ / hv_24x7@PM_PB_LNS_PUMP01\\,chip\\=?@) * 100",
>> + "ScaleUnit": "1%",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "LOCAL_NODE_PUMP_RETRY_RATIO_P23",
>> + "BriefDescription": "LOCAL_NODE_PUMP_RETRY_RATIO_P23",
>> + "MetricExpr": "(hv_24x7@PM_PB_RTY_LNS_PUMP23\\,chip\\=?@ / hv_24x7@PM_PB_LNS_PUMP23\\,chip\\=?@) * 100",
>> + "ScaleUnit": "1%",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "GROUP_PUMP_RETRY_RATIO_P01",
>> + "BriefDescription": "GROUP_PUMP_RETRY_RATIO_P01",
>> + "MetricExpr": "(hv_24x7@PM_PB_RTY_GROUP_PUMP01\\,chip\\=?@ / hv_24x7@PM_PB_GROUP_PUMP01\\,chip\\=?@) * 100",
>> + "ScaleUnit": "1%",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "GROUP_PUMP_RETRY_RATIO_P23",
>> + "BriefDescription": "GROUP_PUMP_RETRY_RATIO_P23",
>> + "MetricExpr": "(hv_24x7@PM_PB_RTY_GROUP_PUMP23\\,chip\\=?@ / hv_24x7@PM_PB_GROUP_PUMP23\\,chip\\=?@) * 100",
>> + "ScaleUnit": "1%",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "TOTAL_GROUP_PUMPS_P01",
>> + "BriefDescription": "TOTAL_GROUP_PUMPS_P01(PER-CYC)",
>> + "MetricExpr": "(hv_24x7@PM_PB_GROUP_PUMP01\\,chip\\=?@ / hv_24x7@PM_PAU_CYC\\,chip\\=?@)",
>> + "ScaleUnit": "4",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "TOTAL_GROUP_PUMPS_P23",
>> + "BriefDescription": "TOTAL_GROUP_PUMPS_P23(PER-CYC)",
>> + "MetricExpr": "(hv_24x7@PM_PB_GROUP_PUMP23\\,chip\\=?@ / hv_24x7@PM_PAU_CYC\\,chip\\=?@)",
>> + "ScaleUnit": "4",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "TOTAL_GROUP_PUMPS_RETRIES_P01",
>> + "BriefDescription": "TOTAL_GROUP_PUMPS_RETRIES_P01(PER-CYC)",
>> + "MetricExpr": "(hv_24x7@PM_PB_RTY_GROUP_PUMP01\\,chip\\=?@ / hv_24x7@PM_PAU_CYC\\,chip\\=?@)",
>> + "ScaleUnit": "4",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "TOTAL_GROUP_PUMPS_RETRIES_P23",
>> + "BriefDescription": "TOTAL_GROUP_PUMPS_RETRIES_P23(PER-CYC)",
>> + "MetricExpr": "(hv_24x7@PM_PB_RTY_GROUP_PUMP23\\,chip\\=?@ / hv_24x7@PM_PAU_CYC\\,chip\\=?@)",
>> + "ScaleUnit": "4",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "REMOTE_NODE_PUMPS_RETRIES_RATIO_P01",
>> + "BriefDescription": "REMOTE_NODE_PUMPS_RETRIES_RATIO_P01",
>> + "MetricExpr": "(hv_24x7@PM_PB_RTY_RNS_PUMP01\\,chip\\=?@ / hv_24x7@PM_PB_RNS_PUMP01\\,chip\\=?@) * 100",
>> + "ScaleUnit": "1%",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "REMOTE_NODE_PUMPS_RETRIES_RATIO_P23",
>> + "BriefDescription": "REMOTE_NODE_PUMPS_RETRIES_RATIO_P23",
>> + "MetricExpr": "(hv_24x7@PM_PB_RTY_RNS_PUMP23\\,chip\\=?@ / hv_24x7@PM_PB_RNS_PUMP23\\,chip\\=?@) * 100",
>> + "ScaleUnit": "1%",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "TOTAL_VECTOR_GROUP_PUMPS_P01",
>> + "BriefDescription": "TOTAL_VECTOR_GROUP_PUMPS_P01(PER-CYC)",
>> + "MetricExpr": "(hv_24x7@PM_PB_VG_PUMP01\\,chip\\=?@ / hv_24x7@PM_PAU_CYC\\,chip\\=?@)",
>> + "ScaleUnit": "4",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "TOTAL_VECTOR_GROUP_PUMPS_P23",
>> + "BriefDescription": "TOTAL_VECTOR_GROUP_PUMPS_P23(PER-CYC)",
>> + "MetricExpr": "(hv_24x7@PM_PB_VG_PUMP23\\,chip\\=?@ / hv_24x7@PM_PAU_CYC\\,chip\\=?@)",
>> + "ScaleUnit": "4",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "TOTAL_LOCAL_NODE_PUMPS_P01",
>> + "BriefDescription": "TOTAL_LOCAL_NODE_PUMPS_P01(PER-CYC)",
>> + "MetricExpr": "(hv_24x7@PM_PB_LNS_PUMP01\\,chip\\=?@ / hv_24x7@PM_PAU_CYC\\,chip\\=?@)",
>> + "ScaleUnit": "4",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "TOTAL_LOCAL_NODE_PUMPS_P23",
>> + "BriefDescription": "TOTAL_LOCAL_NODE_PUMPS_P23(PER-CYC)",
>> + "MetricExpr": "(hv_24x7@PM_PB_LNS_PUMP23\\,chip\\=?@ / hv_24x7@PM_PAU_CYC\\,chip\\=?@)",
>> + "ScaleUnit": "4",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "TOTAL_VECTOR_GROUP_PUMPS_RETRIES_P01",
>> + "BriefDescription": "TOTAL_VECTOR_GROUP_PUMPS_RETRIES_P01(PER-CYC)",
>> + "MetricExpr": "(hv_24x7@PM_PB_RTY_VG_PUMP01\\,chip\\=?@ / hv_24x7@PM_PAU_CYC\\,chip\\=?@)",
>> + "ScaleUnit": "4",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "TOTAL_VECTOR_GROUP_PUMPS_RETRIES_P23",
>> + "BriefDescription": "TOTAL_VECTOR_GROUP_PUMPS_RETRIES_P23(PER-CYC)",
>> + "MetricExpr": "(hv_24x7@PM_PB_RTY_VG_PUMP23\\,chip\\=?@ / hv_24x7@PM_PAU_CYC\\,chip\\=?@)",
>> + "ScaleUnit": "4",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "TOTAL_LOCAL_NODE_PUMPS_RETRIES_P01",
>> + "BriefDescription": "TOTAL_LOCAL_NODE_PUMPS_RETRIES_P01(PER-CYC)",
>> + "MetricExpr": "(hv_24x7@PM_PB_RTY_LNS_PUMP01\\,chip\\=?@ / hv_24x7@PM_PAU_CYC\\,chip\\=?@)",
>> + "ScaleUnit": "4",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "TOTAL_LOCAL_NODE_PUMPS_RETRIES_P23",
>> + "BriefDescription": "TOTAL_LOCAL_NODE_PUMPS_RETRIES_P23(PER-CYC)",
>> + "MetricExpr": "(hv_24x7@PM_PB_RTY_LNS_PUMP23\\,chip\\=?@ / hv_24x7@PM_PAU_CYC\\,chip\\=?@)",
>> + "ScaleUnit": "4",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "TOTAL_REMOTE_NODE_PUMPS_P01",
>> + "BriefDescription": "TOTAL_REMOTE_NODE_PUMPS_P01",
>> + "MetricExpr": "(hv_24x7@PM_PB_RNS_PUMP01\\,chip\\=?@ / hv_24x7@PM_PAU_CYC\\,chip\\=?@)",
>> + "ScaleUnit": "4",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "TOTAL_REMOTE_NODE_PUMPS_P23",
>> + "BriefDescription": "TOTAL_REMOTE_NODE_PUMPS_P23",
>> + "MetricExpr": "(hv_24x7@PM_PB_RNS_PUMP23\\,chip\\=?@ / hv_24x7@PM_PAU_CYC\\,chip\\=?@)",
>> + "ScaleUnit": "4",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "TOTAL_NEAR_NODE_PUMPS_P01",
>> + "BriefDescription": "TOTAL_NEAR_NODE_PUMPS_P01",
>> + "MetricExpr": "(hv_24x7@PM_PB_NNS_PUMP01\\,chip\\=?@ / hv_24x7@PM_PAU_CYC\\,chip\\=?@)",
>> + "ScaleUnit": "4",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "TOTAL_NEAR_NODE_PUMPS_P23",
>> + "BriefDescription": "TOTAL_NEAR_NODE_PUMPS_P23",
>> + "MetricExpr": "(hv_24x7@PM_PB_NNS_PUMP23\\,chip\\=?@ / hv_24x7@PM_PAU_CYC\\,chip\\=?@)",
>> + "ScaleUnit": "4",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "TOTAL_INT_PB_BW",
>> + "BriefDescription": "TOTAL_INT_PB_BW",
>> + "MetricExpr": "(hv_24x7@PM_PB_INT_DATA_XFER\\,chip\\=?@)",
>> + "ScaleUnit": "2.09MB",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "XLINK0_OUT_TOTAL_UTILIZATION",
>> + "BriefDescription": "XLINK0_OUT_TOTAL_UTILIZATION",
>> + "MetricExpr": "((hv_24x7@PM_XLINK0_OUT_ODD_TOTAL_UTIL\\,chip\\=?@ + hv_24x7@PM_XLINK0_OUT_EVEN_TOTAL_UTIL\\,chip\\=?@) / (hv_24x7@PM_XLINK0_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_XLINK0_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
>> + "ScaleUnit": "1%",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "XLINK1_OUT_TOTAL_UTILIZATION",
>> + "BriefDescription": "XLINK1_OUT_TOTAL_UTILIZATION",
>> + "MetricExpr": "((hv_24x7@PM_XLINK1_OUT_ODD_TOTAL_UTIL\\,chip\\=?@ + hv_24x7@PM_XLINK1_OUT_EVEN_TOTAL_UTIL\\,chip\\=?@) / (hv_24x7@PM_XLINK1_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_XLINK1_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
>> + "ScaleUnit": "1%",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "XLINK2_OUT_TOTAL_UTILIZATION",
>> + "BriefDescription": "XLINK2_OUT_TOTAL_UTILIZATION",
>> + "MetricExpr": "((hv_24x7@PM_XLINK2_OUT_ODD_TOTAL_UTIL\\,chip\\=?@ + hv_24x7@PM_XLINK2_OUT_EVEN_TOTAL_UTIL\\,chip\\=?@) / (hv_24x7@PM_XLINK2_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_XLINK2_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
>> + "ScaleUnit": "1%",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "XLINK3_OUT_TOTAL_UTILIZATION",
>> + "BriefDescription": "XLINK3_OUT_TOTAL_UTILIZATION",
>> + "MetricExpr": "((hv_24x7@PM_XLINK3_OUT_ODD_TOTAL_UTIL\\,chip\\=?@ + hv_24x7@PM_XLINK3_OUT_EVEN_TOTAL_UTIL\\,chip\\=?@) / (hv_24x7@PM_XLINK3_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_XLINK3_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
>> + "ScaleUnit": "1%",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "XLINK4_OUT_TOTAL_UTILIZATION",
>> + "BriefDescription": "XLINK4_OUT_TOTAL_UTILIZATION",
>> + "MetricExpr": "((hv_24x7@PM_XLINK4_OUT_ODD_TOTAL_UTIL\\,chip\\=?@ + hv_24x7@PM_XLINK4_OUT_EVEN_TOTAL_UTIL\\,chip\\=?@) / (hv_24x7@PM_XLINK4_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_XLINK4_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
>> + "ScaleUnit": "1%",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "XLINK5_OUT_TOTAL_UTILIZATION",
>> + "BriefDescription": "XLINK5_OUT_TOTAL_UTILIZATION",
>> + "MetricExpr": "((hv_24x7@PM_XLINK5_OUT_ODD_TOTAL_UTIL\\,chip\\=?@ + hv_24x7@PM_XLINK5_OUT_EVEN_TOTAL_UTIL\\,chip\\=?@) / (hv_24x7@PM_XLINK5_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_XLINK5_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
>> + "ScaleUnit": "1%",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "XLINK6_OUT_TOTAL_UTILIZATION",
>> + "BriefDescription": "XLINK6_OUT_TOTAL_UTILIZATION",
>> + "MetricExpr": "((hv_24x7@PM_XLINK6_OUT_ODD_TOTAL_UTIL\\,chip\\=?@ + hv_24x7@PM_XLINK6_OUT_EVEN_TOTAL_UTIL\\,chip\\=?@) / (hv_24x7@PM_XLINK6_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_XLINK6_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
>> + "ScaleUnit": "1%",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "XLINK7_OUT_TOTAL_UTILIZATION",
>> + "BriefDescription": "XLINK7_OUT_TOTAL_UTILIZATION",
>> + "MetricExpr": "((hv_24x7@PM_XLINK7_OUT_ODD_TOTAL_UTIL\\,chip\\=?@ + hv_24x7@PM_XLINK7_OUT_EVEN_TOTAL_UTIL\\,chip\\=?@) / (hv_24x7@PM_XLINK7_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_XLINK7_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
>> + "ScaleUnit": "1%",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "XLINK0_OUT_DATA_UTILIZATION",
>> + "BriefDescription": "XLINK0_OUT_DATA_UTILIZATION",
>> + "MetricExpr": "((hv_24x7@PM_XLINK0_OUT_ODD_DATA\\,chip\\=?@ + hv_24x7@PM_XLINK0_OUT_EVEN_DATA\\,chip\\=?@) / (hv_24x7@PM_XLINK0_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_XLINK0_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
>> + "ScaleUnit": "1.063%",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "XLINK1_OUT_DATA_UTILIZATION",
>> + "BriefDescription": "XLINK1_OUT_DATA_UTILIZATION",
>> + "MetricExpr": "((hv_24x7@PM_XLINK1_OUT_ODD_DATA\\,chip\\=?@ + hv_24x7@PM_XLINK1_OUT_EVEN_DATA\\,chip\\=?@) / (hv_24x7@PM_XLINK1_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_XLINK1_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
>> + "ScaleUnit": "1.063%",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "XLINK2_OUT_DATA_UTILIZATION",
>> + "BriefDescription": "XLINK2_OUT_DATA_UTILIZATION",
>> + "MetricExpr": "((hv_24x7@PM_XLINK2_OUT_ODD_DATA\\,chip\\=?@ + hv_24x7@PM_XLINK2_OUT_EVEN_DATA\\,chip\\=?@) / (hv_24x7@PM_XLINK2_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_XLINK2_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
>> + "ScaleUnit": "1.063%",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "XLINK3_OUT_DATA_UTILIZATION",
>> + "BriefDescription": "XLINK3_OUT_DATA_UTILIZATION",
>> + "MetricExpr": "((hv_24x7@PM_XLINK3_OUT_ODD_DATA\\,chip\\=?@ + hv_24x7@PM_XLINK3_OUT_EVEN_DATA\\,chip\\=?@) / (hv_24x7@PM_XLINK3_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_XLINK3_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
>> + "ScaleUnit": "1.063%",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "XLINK4_OUT_DATA_UTILIZATION",
>> + "BriefDescription": "XLINK4_OUT_DATA_UTILIZATION",
>> + "MetricExpr": "((hv_24x7@PM_XLINK4_OUT_ODD_DATA\\,chip\\=?@ + hv_24x7@PM_XLINK4_OUT_EVEN_DATA\\,chip\\=?@) / (hv_24x7@PM_XLINK4_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_XLINK4_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
>> + "ScaleUnit": "1.063%",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "XLINK5_OUT_DATA_UTILIZATION",
>> + "BriefDescription": "XLINK5_OUT_DATA_UTILIZATION",
>> + "MetricExpr": "((hv_24x7@PM_XLINK5_OUT_ODD_DATA\\,chip\\=?@ + hv_24x7@PM_XLINK5_OUT_EVEN_DATA\\,chip\\=?@) / (hv_24x7@PM_XLINK5_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_XLINK5_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
>> + "ScaleUnit": "1.063%",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "XLINK6_OUT_DATA_UTILIZATION",
>> + "BriefDescription": "XLINK6_OUT_DATA_UTILIZATION",
>> + "MetricExpr": "((hv_24x7@PM_XLINK6_OUT_ODD_DATA\\,chip\\=?@ + hv_24x7@PM_XLINK6_OUT_EVEN_DATA\\,chip\\=?@) / (hv_24x7@PM_XLINK6_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_XLINK6_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
>> + "ScaleUnit": "1.063%",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "XLINK7_OUT_DATA_UTILIZATION",
>> + "BriefDescription": "XLINK7_OUT_DATA_UTILIZATION",
>> + "MetricExpr": "((hv_24x7@PM_XLINK7_OUT_ODD_DATA\\,chip\\=?@ + hv_24x7@PM_XLINK7_OUT_EVEN_DATA\\,chip\\=?@) / (hv_24x7@PM_XLINK7_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_XLINK7_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
>> + "ScaleUnit": "1.063%",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "ALINK0_OUT_TOTAL_UTILIZATION",
>> + "BriefDescription": "ALINK0_OUT_TOTAL_UTILIZATION",
>> + "MetricExpr": "((hv_24x7@PM_ALINK0_OUT_ODD_TOTAL_UTIL\\,chip\\=?@ + hv_24x7@PM_ALINK0_OUT_EVEN_TOTAL_UTIL\\,chip\\=?@) / (hv_24x7@PM_ALINK0_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_ALINK0_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
>> + "ScaleUnit": "1%",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "ALINK1_OUT_TOTAL_UTILIZATION",
>> + "BriefDescription": "ALINK1_OUT_TOTAL_UTILIZATION",
>> + "MetricExpr": "((hv_24x7@PM_ALINK1_OUT_ODD_TOTAL_UTIL\\,chip\\=?@ + hv_24x7@PM_ALINK1_OUT_EVEN_TOTAL_UTIL\\,chip\\=?@) / (hv_24x7@PM_ALINK1_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_ALINK1_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
>> + "ScaleUnit": "1%",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "ALINK2_OUT_TOTAL_UTILIZATION",
>> + "BriefDescription": "ALINK2_OUT_TOTAL_UTILIZATION",
>> + "MetricExpr": "((hv_24x7@PM_ALINK2_OUT_ODD_TOTAL_UTIL\\,chip\\=?@ + hv_24x7@PM_ALINK2_OUT_EVEN_TOTAL_UTIL\\,chip\\=?@) / (hv_24x7@PM_ALINK2_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_ALINK2_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
>> + "ScaleUnit": "1%",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "ALINK3_OUT_TOTAL_UTILIZATION",
>> + "BriefDescription": "ALINK3_OUT_TOTAL_UTILIZATION",
>> + "MetricExpr": "((hv_24x7@PM_ALINK3_OUT_ODD_TOTAL_UTIL\\,chip\\=?@ + hv_24x7@PM_ALINK3_OUT_EVEN_TOTAL_UTIL\\,chip\\=?@) / (hv_24x7@PM_ALINK3_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_ALINK3_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
>> + "ScaleUnit": "1%",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "ALINK4_OUT_TOTAL_UTILIZATION",
>> + "BriefDescription": "ALINK4_OUT_TOTAL_UTILIZATION",
>> + "MetricExpr": "((hv_24x7@PM_ALINK4_OUT_ODD_TOTAL_UTIL\\,chip\\=?@ + hv_24x7@PM_ALINK4_OUT_EVEN_TOTAL_UTIL\\,chip\\=?@) / (hv_24x7@PM_ALINK4_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_ALINK4_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
>> + "ScaleUnit": "1%",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "ALINK5_OUT_TOTAL_UTILIZATION",
>> + "BriefDescription": "ALINK5_OUT_TOTAL_UTILIZATION",
>> + "MetricExpr": "((hv_24x7@PM_ALINK5_OUT_ODD_TOTAL_UTIL\\,chip\\=?@ + hv_24x7@PM_ALINK5_OUT_EVEN_TOTAL_UTIL\\,chip\\=?@) / (hv_24x7@PM_ALINK5_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_ALINK5_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
>> + "ScaleUnit": "1%",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "ALINK6_OUT_TOTAL_UTILIZATION",
>> + "BriefDescription": "ALINK6_OUT_TOTAL_UTILIZATION",
>> + "MetricExpr": "((hv_24x7@PM_ALINK6_OUT_ODD_TOTAL_UTIL\\,chip\\=?@ + hv_24x7@PM_ALINK6_OUT_EVEN_TOTAL_UTIL\\,chip\\=?@) / (hv_24x7@PM_ALINK6_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_ALINK6_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
>> + "ScaleUnit": "1%",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "ALINK7_OUT_TOTAL_UTILIZATION",
>> + "BriefDescription": "ALINK7_OUT_TOTAL_UTILIZATION",
>> + "MetricExpr": "((hv_24x7@PM_ALINK7_OUT_ODD_TOTAL_UTIL\\,chip\\=?@ + hv_24x7@PM_ALINK7_OUT_EVEN_TOTAL_UTIL\\,chip\\=?@) / (hv_24x7@PM_ALINK7_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_ALINK7_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
>> + "ScaleUnit": "1%",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "ALINK0_OUT_DATA_UTILIZATION",
>> + "BriefDescription": "ALINK0_OUT_DATA_UTILIZATION",
>> + "MetricExpr": "((hv_24x7@PM_ALINK0_OUT_ODD_DATA\\,chip\\=?@ + hv_24x7@PM_ALINK0_OUT_EVEN_DATA\\,chip\\=?@) / (hv_24x7@PM_ALINK0_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_ALINK0_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
>> + "ScaleUnit": "1.063%",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "ALINK1_OUT_DATA_UTILIZATION",
>> + "BriefDescription": "ALINK1_OUT_DATA_UTILIZATION",
>> + "MetricExpr": "((hv_24x7@PM_ALINK1_OUT_ODD_DATA\\,chip\\=?@ + hv_24x7@PM_ALINK1_OUT_EVEN_DATA\\,chip\\=?@) / (hv_24x7@PM_ALINK1_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_ALINK1_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
>> + "ScaleUnit": "1.063%",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "ALINK2_OUT_DATA_UTILIZATION",
>> + "BriefDescription": "ALINK2_OUT_DATA_UTILIZATION",
>> + "MetricExpr": "((hv_24x7@PM_ALINK2_OUT_ODD_DATA\\,chip\\=?@ + hv_24x7@PM_ALINK2_OUT_EVEN_DATA\\,chip\\=?@) / (hv_24x7@PM_ALINK2_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_ALINK2_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
>> + "ScaleUnit": "1.063%",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "ALINK3_OUT_DATA_UTILIZATION",
>> + "BriefDescription": "ALINK3_OUT_DATA_UTILIZATION",
>> + "MetricExpr": "((hv_24x7@PM_ALINK3_OUT_ODD_DATA\\,chip\\=?@ + hv_24x7@PM_ALINK3_OUT_EVEN_DATA\\,chip\\=?@) / (hv_24x7@PM_ALINK3_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_ALINK3_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
>> + "ScaleUnit": "1.063%",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "ALINK4_OUT_DATA_UTILIZATION",
>> + "BriefDescription": "ALINK4_OUT_DATA_UTILIZATION",
>> + "MetricExpr": "((hv_24x7@PM_ALINK4_OUT_ODD_DATA\\,chip\\=?@ + hv_24x7@PM_ALINK4_OUT_EVEN_DATA\\,chip\\=?@) / (hv_24x7@PM_ALINK4_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_ALINK4_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
>> + "ScaleUnit": "1.063%",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "ALINK5_OUT_DATA_UTILIZATION",
>> + "BriefDescription": "ALINK5_OUT_DATA_UTILIZATION",
>> + "MetricExpr": "((hv_24x7@PM_ALINK5_OUT_ODD_DATA\\,chip\\=?@ + hv_24x7@PM_ALINK5_OUT_EVEN_DATA\\,chip\\=?@) / (hv_24x7@PM_ALINK5_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_ALINK5_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
>> + "ScaleUnit": "1.063%",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "ALINK6_OUT_DATA_UTILIZATION",
>> + "BriefDescription": "ALINK6_OUT_DATA_UTILIZATION",
>> + "MetricExpr": "((hv_24x7@PM_ALINK6_OUT_ODD_DATA\\,chip\\=?@ + hv_24x7@PM_ALINK6_OUT_EVEN_DATA\\,chip\\=?@) / (hv_24x7@PM_ALINK6_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_ALINK6_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
>> + "ScaleUnit": "1.063%",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "ALINK7_OUT_DATA_UTILIZATION",
>> + "BriefDescription": "ALINK7_OUT_DATA_UTILIZATION",
>> + "MetricExpr": "((hv_24x7@PM_ALINK7_OUT_ODD_DATA\\,chip\\=?@ + hv_24x7@PM_ALINK7_OUT_EVEN_DATA\\,chip\\=?@) / (hv_24x7@PM_ALINK7_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_ALINK7_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
>> + "ScaleUnit": "1.063%",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "TOTAL_DATA_BANDWIDTH_TRANSFERRED_OVER_PB_PCI1",
>> + "BriefDescription": "TOTAL_DATA_BANDWIDTH_TRANSFERRED_OVER_PB_PCI1",
>> + "MetricExpr": "(hv_24x7@PM_PCI1_32B_INOUT\\,chip\\=?@)",
>> + "ScaleUnit": "3.28e-2MB",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "TOTAL_DATA_BANDWIDTH_TRANSFERRED_OVER_PB_PCI0",
>> + "BriefDescription": "TOTAL_DATA_BANDWIDTH_TRANSFERRED_OVER_PB_PCI0",
>> + "MetricExpr": "(hv_24x7@PM_PCI0_32B_INOUT\\,chip\\=?@)",
>> + "ScaleUnit": "3.28e-2MB",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "TOTAL_MCS_READ_BW_MC0_CHAN01",
>> + "BriefDescription": "TOTAL_MCS_READ_BW_MC0_CHAN01",
>> + "MetricExpr": "(hv_24x7@PM_MCS_128B_RD_DATA_BLOCKS_MC0_CHAN01\\,chip\\=?@)",
>> + "ScaleUnit": "5.24e-1MB",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "TOTAL_MCS_READ_BW_MC1_CHAN01",
>> + "BriefDescription": "TOTAL_MCS_READ_BW_MC1_CHAN01",
>> + "MetricExpr": "(hv_24x7@PM_MCS_128B_RD_DATA_BLOCKS_MC1_CHAN01\\,chip\\=?@)",
>> + "ScaleUnit": "5.24e-1MB",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "TOTAL_MCS_READ_BW_MC2_CHAN01",
>> + "BriefDescription": "TOTAL_MCS_READ_BW_MC2_CHAN01",
>> + "MetricExpr": "(hv_24x7@PM_MCS_128B_RD_DATA_BLOCKS_MC2_CHAN01\\,chip\\=?@)",
>> + "ScaleUnit": "5.24e-1MB",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "TOTAL_MCS_READ_BW_MC3_CHAN01",
>> + "BriefDescription": "TOTAL_MCS_READ_BW_MC3_CHAN01",
>> + "MetricExpr": "(hv_24x7@PM_MCS_128B_RD_DATA_BLOCKS_MC3_CHAN01\\,chip\\=?@)",
>> + "ScaleUnit": "5.24e-1MB",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "TOTAL_MCS_WRITE_BW_MC0_CHAN01",
>> + "BriefDescription": "TOTAL_MCS_WRITE_BW_MC0_CHAN01",
>> + "MetricExpr": "(hv_24x7@PM_MCS_64B_WR_DATA_BLOCKS_MC0_CHAN01\\,chip\\=?@)",
>> + "ScaleUnit": "2.6e-1MB",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "TOTAL_MCS_WRITE_BW_MC1_CHAN01",
>> + "BriefDescription": "TOTAL_MCS_WRITE_BW_MC1_CHAN01",
>> + "MetricExpr": "(hv_24x7@PM_MCS_64B_WR_DATA_BLOCKS_MC1_CHAN01\\,chip\\=?@)",
>> + "ScaleUnit": "2.6e-1MB",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "TOTAL_MCS_WRITE_BW_MC2_CHAN01",
>> + "BriefDescription": "TOTAL_MCS_WRITE_BW_MC2_CHAN01",
>> + "MetricExpr": "(hv_24x7@PM_MCS_64B_WR_DATA_BLOCKS_MC2_CHAN01\\,chip\\=?@)",
>> + "ScaleUnit": "2.6e-1MB",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricName": "TOTAL_MCS_WRITE_BW_MC3_CHAN01",
>> + "BriefDescription": "TOTAL_MCS_WRITE_BW_MC3_CHAN01",
>> + "MetricExpr": "(hv_24x7@PM_MCS_64B_WR_DATA_BLOCKS_MC3_CHAN01\\,chip\\=?@)",
>> + "ScaleUnit": "2.6e-1MB",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricExpr": "(hv_24x7@PM_MCS_128B_RD_DATA_BLOCKS_MC0_CHAN01\\,chip\\=?@ + hv_24x7@PM_MCS_128B_RD_DATA_BLOCKS_MC1_CHAN01\\,chip\\=?@ + hv_24x7@PM_MCS_128B_RD_DATA_BLOCKS_MC2_CHAN01\\,chip\\=?@ + hv_24x7@PM_MCS_128B_RD_DATA_BLOCKS_MC3_CHAN01\\,chip\\=?@)",
>> + "MetricName": "Memory_RD_BW_Chip",
>
> The pattern up until this point was "MetricName", then "BriefDescription",
> then "MetricExpr". I think it would be helpful to continue that here,
> and for the next two as well. That should include _having_ a description,
> obviously. :-)
>
Ok I will update it.
Thanks,
Kajol Jain
>> + "MetricGroup": "Memory_BW",
>> + "ScaleUnit": "5.24e-1MB",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricExpr": "(hv_24x7@PM_MCS_64B_WR_DATA_BLOCKS_MC0_CHAN01\\,chip\\=?@ + hv_24x7@PM_MCS_64B_WR_DATA_BLOCKS_MC1_CHAN01\\,chip\\=?@ + hv_24x7@PM_MCS_64B_WR_DATA_BLOCKS_MC2_CHAN01\\,chip\\=?@ + hv_24x7@PM_MCS_64B_WR_DATA_BLOCKS_MC3_CHAN01\\,chip\\=?@ )",
>> + "MetricName": "Memory_WR_BW_Chip",
>> + "MetricGroup": "Memory_BW",
>> + "ScaleUnit": "2.6e-1MB",
>> + "AggregationMode": "PerChip"
>> + },
>> + {
>> + "MetricExpr": "(hv_24x7@PM_PAU_CYC\\,chip\\=?@ )",
>> + "MetricName": "PowerBUS_Frequency",
>> + "ScaleUnit": "2.56e-7GHz",
>> + "AggregationMode": "PerChip"
>> + }
>> +]
>> --
>
> PC
>
^ permalink raw reply
* [PATCH v2] perf vendor events power10: Adds 24x7 nest metric events for power10 platform
From: Kajol Jain @ 2021-06-28 6:49 UTC (permalink / raw)
To: acme
Cc: ravi.bangoria, atrajeev, rnsastry, kjain, linuxppc-dev,
linux-kernel, linux-perf-users, maddy, pc, jolsa
Patch adds 24x7 nest metric events for POWER10.
Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com>
Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
---
.../arch/powerpc/power10/nest_metrics.json | 424 ++++++++++++++++++
1 file changed, 424 insertions(+)
create mode 100644 tools/perf/pmu-events/arch/powerpc/power10/nest_metrics.json
---
Changelog:
v1 -> v2
- Removed "BriefDescription" field as its value was same as "MetricName"
field as suggested by Paul A. Clarke
- Added Tested-by tag.
---
diff --git a/tools/perf/pmu-events/arch/powerpc/power10/nest_metrics.json b/tools/perf/pmu-events/arch/powerpc/power10/nest_metrics.json
new file mode 100644
index 000000000000..8ba3e81c9808
--- /dev/null
+++ b/tools/perf/pmu-events/arch/powerpc/power10/nest_metrics.json
@@ -0,0 +1,424 @@
+[
+ {
+ "MetricName": "VEC_GROUP_PUMP_RETRY_RATIO_P01",
+ "MetricExpr": "(hv_24x7@PM_PB_RTY_VG_PUMP01\\,chip\\=?@ / hv_24x7@PM_PB_VG_PUMP01\\,chip\\=?@) * 100",
+ "ScaleUnit": "1%",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "VEC_GROUP_PUMP_RETRY_RATIO_P23",
+ "MetricExpr": "(hv_24x7@PM_PB_RTY_VG_PUMP23\\,chip\\=?@ / hv_24x7@PM_PB_VG_PUMP23\\,chip\\=?@) * 100",
+ "ScaleUnit": "1%",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "LOCAL_NODE_PUMP_RETRY_RATIO_P01",
+ "MetricExpr": "(hv_24x7@PM_PB_RTY_LNS_PUMP01\\,chip\\=?@ / hv_24x7@PM_PB_LNS_PUMP01\\,chip\\=?@) * 100",
+ "ScaleUnit": "1%",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "LOCAL_NODE_PUMP_RETRY_RATIO_P23",
+ "MetricExpr": "(hv_24x7@PM_PB_RTY_LNS_PUMP23\\,chip\\=?@ / hv_24x7@PM_PB_LNS_PUMP23\\,chip\\=?@) * 100",
+ "ScaleUnit": "1%",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "GROUP_PUMP_RETRY_RATIO_P01",
+ "MetricExpr": "(hv_24x7@PM_PB_RTY_GROUP_PUMP01\\,chip\\=?@ / hv_24x7@PM_PB_GROUP_PUMP01\\,chip\\=?@) * 100",
+ "ScaleUnit": "1%",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "GROUP_PUMP_RETRY_RATIO_P23",
+ "MetricExpr": "(hv_24x7@PM_PB_RTY_GROUP_PUMP23\\,chip\\=?@ / hv_24x7@PM_PB_GROUP_PUMP23\\,chip\\=?@) * 100",
+ "ScaleUnit": "1%",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "TOTAL_GROUP_PUMPS_P01",
+ "MetricExpr": "(hv_24x7@PM_PB_GROUP_PUMP01\\,chip\\=?@ / hv_24x7@PM_PAU_CYC\\,chip\\=?@)",
+ "ScaleUnit": "4",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "TOTAL_GROUP_PUMPS_P23",
+ "MetricExpr": "(hv_24x7@PM_PB_GROUP_PUMP23\\,chip\\=?@ / hv_24x7@PM_PAU_CYC\\,chip\\=?@)",
+ "ScaleUnit": "4",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "TOTAL_GROUP_PUMPS_RETRIES_P01",
+ "MetricExpr": "(hv_24x7@PM_PB_RTY_GROUP_PUMP01\\,chip\\=?@ / hv_24x7@PM_PAU_CYC\\,chip\\=?@)",
+ "ScaleUnit": "4",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "TOTAL_GROUP_PUMPS_RETRIES_P23",
+ "MetricExpr": "(hv_24x7@PM_PB_RTY_GROUP_PUMP23\\,chip\\=?@ / hv_24x7@PM_PAU_CYC\\,chip\\=?@)",
+ "ScaleUnit": "4",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "REMOTE_NODE_PUMPS_RETRIES_RATIO_P01",
+ "MetricExpr": "(hv_24x7@PM_PB_RTY_RNS_PUMP01\\,chip\\=?@ / hv_24x7@PM_PB_RNS_PUMP01\\,chip\\=?@) * 100",
+ "ScaleUnit": "1%",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "REMOTE_NODE_PUMPS_RETRIES_RATIO_P23",
+ "MetricExpr": "(hv_24x7@PM_PB_RTY_RNS_PUMP23\\,chip\\=?@ / hv_24x7@PM_PB_RNS_PUMP23\\,chip\\=?@) * 100",
+ "ScaleUnit": "1%",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "TOTAL_VECTOR_GROUP_PUMPS_P01",
+ "MetricExpr": "(hv_24x7@PM_PB_VG_PUMP01\\,chip\\=?@ / hv_24x7@PM_PAU_CYC\\,chip\\=?@)",
+ "ScaleUnit": "4",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "TOTAL_VECTOR_GROUP_PUMPS_P23",
+ "MetricExpr": "(hv_24x7@PM_PB_VG_PUMP23\\,chip\\=?@ / hv_24x7@PM_PAU_CYC\\,chip\\=?@)",
+ "ScaleUnit": "4",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "TOTAL_LOCAL_NODE_PUMPS_P01",
+ "MetricExpr": "(hv_24x7@PM_PB_LNS_PUMP01\\,chip\\=?@ / hv_24x7@PM_PAU_CYC\\,chip\\=?@)",
+ "ScaleUnit": "4",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "TOTAL_LOCAL_NODE_PUMPS_P23",
+ "MetricExpr": "(hv_24x7@PM_PB_LNS_PUMP23\\,chip\\=?@ / hv_24x7@PM_PAU_CYC\\,chip\\=?@)",
+ "ScaleUnit": "4",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "TOTAL_VECTOR_GROUP_PUMPS_RETRIES_P01",
+ "MetricExpr": "(hv_24x7@PM_PB_RTY_VG_PUMP01\\,chip\\=?@ / hv_24x7@PM_PAU_CYC\\,chip\\=?@)",
+ "ScaleUnit": "4",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "TOTAL_VECTOR_GROUP_PUMPS_RETRIES_P23",
+ "MetricExpr": "(hv_24x7@PM_PB_RTY_VG_PUMP23\\,chip\\=?@ / hv_24x7@PM_PAU_CYC\\,chip\\=?@)",
+ "ScaleUnit": "4",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "TOTAL_LOCAL_NODE_PUMPS_RETRIES_P01",
+ "MetricExpr": "(hv_24x7@PM_PB_RTY_LNS_PUMP01\\,chip\\=?@ / hv_24x7@PM_PAU_CYC\\,chip\\=?@)",
+ "ScaleUnit": "4",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "TOTAL_LOCAL_NODE_PUMPS_RETRIES_P23",
+ "MetricExpr": "(hv_24x7@PM_PB_RTY_LNS_PUMP23\\,chip\\=?@ / hv_24x7@PM_PAU_CYC\\,chip\\=?@)",
+ "ScaleUnit": "4",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "TOTAL_REMOTE_NODE_PUMPS_P01",
+ "MetricExpr": "(hv_24x7@PM_PB_RNS_PUMP01\\,chip\\=?@ / hv_24x7@PM_PAU_CYC\\,chip\\=?@)",
+ "ScaleUnit": "4",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "TOTAL_REMOTE_NODE_PUMPS_P23",
+ "MetricExpr": "(hv_24x7@PM_PB_RNS_PUMP23\\,chip\\=?@ / hv_24x7@PM_PAU_CYC\\,chip\\=?@)",
+ "ScaleUnit": "4",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "TOTAL_NEAR_NODE_PUMPS_P01",
+ "MetricExpr": "(hv_24x7@PM_PB_NNS_PUMP01\\,chip\\=?@ / hv_24x7@PM_PAU_CYC\\,chip\\=?@)",
+ "ScaleUnit": "4",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "TOTAL_NEAR_NODE_PUMPS_P23",
+ "MetricExpr": "(hv_24x7@PM_PB_NNS_PUMP23\\,chip\\=?@ / hv_24x7@PM_PAU_CYC\\,chip\\=?@)",
+ "ScaleUnit": "4",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "TOTAL_INT_PB_BW",
+ "MetricExpr": "(hv_24x7@PM_PB_INT_DATA_XFER\\,chip\\=?@)",
+ "ScaleUnit": "2.09MB",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "XLINK0_OUT_TOTAL_UTILIZATION",
+ "MetricExpr": "((hv_24x7@PM_XLINK0_OUT_ODD_TOTAL_UTIL\\,chip\\=?@ + hv_24x7@PM_XLINK0_OUT_EVEN_TOTAL_UTIL\\,chip\\=?@) / (hv_24x7@PM_XLINK0_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_XLINK0_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
+ "ScaleUnit": "1%",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "XLINK1_OUT_TOTAL_UTILIZATION",
+ "MetricExpr": "((hv_24x7@PM_XLINK1_OUT_ODD_TOTAL_UTIL\\,chip\\=?@ + hv_24x7@PM_XLINK1_OUT_EVEN_TOTAL_UTIL\\,chip\\=?@) / (hv_24x7@PM_XLINK1_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_XLINK1_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
+ "ScaleUnit": "1%",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "XLINK2_OUT_TOTAL_UTILIZATION",
+ "MetricExpr": "((hv_24x7@PM_XLINK2_OUT_ODD_TOTAL_UTIL\\,chip\\=?@ + hv_24x7@PM_XLINK2_OUT_EVEN_TOTAL_UTIL\\,chip\\=?@) / (hv_24x7@PM_XLINK2_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_XLINK2_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
+ "ScaleUnit": "1%",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "XLINK3_OUT_TOTAL_UTILIZATION",
+ "MetricExpr": "((hv_24x7@PM_XLINK3_OUT_ODD_TOTAL_UTIL\\,chip\\=?@ + hv_24x7@PM_XLINK3_OUT_EVEN_TOTAL_UTIL\\,chip\\=?@) / (hv_24x7@PM_XLINK3_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_XLINK3_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
+ "ScaleUnit": "1%",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "XLINK4_OUT_TOTAL_UTILIZATION",
+ "MetricExpr": "((hv_24x7@PM_XLINK4_OUT_ODD_TOTAL_UTIL\\,chip\\=?@ + hv_24x7@PM_XLINK4_OUT_EVEN_TOTAL_UTIL\\,chip\\=?@) / (hv_24x7@PM_XLINK4_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_XLINK4_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
+ "ScaleUnit": "1%",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "XLINK5_OUT_TOTAL_UTILIZATION",
+ "MetricExpr": "((hv_24x7@PM_XLINK5_OUT_ODD_TOTAL_UTIL\\,chip\\=?@ + hv_24x7@PM_XLINK5_OUT_EVEN_TOTAL_UTIL\\,chip\\=?@) / (hv_24x7@PM_XLINK5_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_XLINK5_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
+ "ScaleUnit": "1%",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "XLINK6_OUT_TOTAL_UTILIZATION",
+ "MetricExpr": "((hv_24x7@PM_XLINK6_OUT_ODD_TOTAL_UTIL\\,chip\\=?@ + hv_24x7@PM_XLINK6_OUT_EVEN_TOTAL_UTIL\\,chip\\=?@) / (hv_24x7@PM_XLINK6_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_XLINK6_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
+ "ScaleUnit": "1%",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "XLINK7_OUT_TOTAL_UTILIZATION",
+ "MetricExpr": "((hv_24x7@PM_XLINK7_OUT_ODD_TOTAL_UTIL\\,chip\\=?@ + hv_24x7@PM_XLINK7_OUT_EVEN_TOTAL_UTIL\\,chip\\=?@) / (hv_24x7@PM_XLINK7_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_XLINK7_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
+ "ScaleUnit": "1%",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "XLINK0_OUT_DATA_UTILIZATION",
+ "MetricExpr": "((hv_24x7@PM_XLINK0_OUT_ODD_DATA\\,chip\\=?@ + hv_24x7@PM_XLINK0_OUT_EVEN_DATA\\,chip\\=?@) / (hv_24x7@PM_XLINK0_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_XLINK0_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
+ "ScaleUnit": "1.063%",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "XLINK1_OUT_DATA_UTILIZATION",
+ "MetricExpr": "((hv_24x7@PM_XLINK1_OUT_ODD_DATA\\,chip\\=?@ + hv_24x7@PM_XLINK1_OUT_EVEN_DATA\\,chip\\=?@) / (hv_24x7@PM_XLINK1_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_XLINK1_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
+ "ScaleUnit": "1.063%",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "XLINK2_OUT_DATA_UTILIZATION",
+ "MetricExpr": "((hv_24x7@PM_XLINK2_OUT_ODD_DATA\\,chip\\=?@ + hv_24x7@PM_XLINK2_OUT_EVEN_DATA\\,chip\\=?@) / (hv_24x7@PM_XLINK2_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_XLINK2_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
+ "ScaleUnit": "1.063%",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "XLINK3_OUT_DATA_UTILIZATION",
+ "MetricExpr": "((hv_24x7@PM_XLINK3_OUT_ODD_DATA\\,chip\\=?@ + hv_24x7@PM_XLINK3_OUT_EVEN_DATA\\,chip\\=?@) / (hv_24x7@PM_XLINK3_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_XLINK3_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
+ "ScaleUnit": "1.063%",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "XLINK4_OUT_DATA_UTILIZATION",
+ "MetricExpr": "((hv_24x7@PM_XLINK4_OUT_ODD_DATA\\,chip\\=?@ + hv_24x7@PM_XLINK4_OUT_EVEN_DATA\\,chip\\=?@) / (hv_24x7@PM_XLINK4_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_XLINK4_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
+ "ScaleUnit": "1.063%",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "XLINK5_OUT_DATA_UTILIZATION",
+ "MetricExpr": "((hv_24x7@PM_XLINK5_OUT_ODD_DATA\\,chip\\=?@ + hv_24x7@PM_XLINK5_OUT_EVEN_DATA\\,chip\\=?@) / (hv_24x7@PM_XLINK5_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_XLINK5_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
+ "ScaleUnit": "1.063%",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "XLINK6_OUT_DATA_UTILIZATION",
+ "MetricExpr": "((hv_24x7@PM_XLINK6_OUT_ODD_DATA\\,chip\\=?@ + hv_24x7@PM_XLINK6_OUT_EVEN_DATA\\,chip\\=?@) / (hv_24x7@PM_XLINK6_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_XLINK6_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
+ "ScaleUnit": "1.063%",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "XLINK7_OUT_DATA_UTILIZATION",
+ "MetricExpr": "((hv_24x7@PM_XLINK7_OUT_ODD_DATA\\,chip\\=?@ + hv_24x7@PM_XLINK7_OUT_EVEN_DATA\\,chip\\=?@) / (hv_24x7@PM_XLINK7_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_XLINK7_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
+ "ScaleUnit": "1.063%",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "ALINK0_OUT_TOTAL_UTILIZATION",
+ "MetricExpr": "((hv_24x7@PM_ALINK0_OUT_ODD_TOTAL_UTIL\\,chip\\=?@ + hv_24x7@PM_ALINK0_OUT_EVEN_TOTAL_UTIL\\,chip\\=?@) / (hv_24x7@PM_ALINK0_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_ALINK0_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
+ "ScaleUnit": "1%",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "ALINK1_OUT_TOTAL_UTILIZATION",
+ "MetricExpr": "((hv_24x7@PM_ALINK1_OUT_ODD_TOTAL_UTIL\\,chip\\=?@ + hv_24x7@PM_ALINK1_OUT_EVEN_TOTAL_UTIL\\,chip\\=?@) / (hv_24x7@PM_ALINK1_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_ALINK1_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
+ "ScaleUnit": "1%",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "ALINK2_OUT_TOTAL_UTILIZATION",
+ "MetricExpr": "((hv_24x7@PM_ALINK2_OUT_ODD_TOTAL_UTIL\\,chip\\=?@ + hv_24x7@PM_ALINK2_OUT_EVEN_TOTAL_UTIL\\,chip\\=?@) / (hv_24x7@PM_ALINK2_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_ALINK2_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
+ "ScaleUnit": "1%",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "ALINK3_OUT_TOTAL_UTILIZATION",
+ "MetricExpr": "((hv_24x7@PM_ALINK3_OUT_ODD_TOTAL_UTIL\\,chip\\=?@ + hv_24x7@PM_ALINK3_OUT_EVEN_TOTAL_UTIL\\,chip\\=?@) / (hv_24x7@PM_ALINK3_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_ALINK3_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
+ "ScaleUnit": "1%",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "ALINK4_OUT_TOTAL_UTILIZATION",
+ "MetricExpr": "((hv_24x7@PM_ALINK4_OUT_ODD_TOTAL_UTIL\\,chip\\=?@ + hv_24x7@PM_ALINK4_OUT_EVEN_TOTAL_UTIL\\,chip\\=?@) / (hv_24x7@PM_ALINK4_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_ALINK4_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
+ "ScaleUnit": "1%",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "ALINK5_OUT_TOTAL_UTILIZATION",
+ "MetricExpr": "((hv_24x7@PM_ALINK5_OUT_ODD_TOTAL_UTIL\\,chip\\=?@ + hv_24x7@PM_ALINK5_OUT_EVEN_TOTAL_UTIL\\,chip\\=?@) / (hv_24x7@PM_ALINK5_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_ALINK5_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
+ "ScaleUnit": "1%",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "ALINK6_OUT_TOTAL_UTILIZATION",
+ "MetricExpr": "((hv_24x7@PM_ALINK6_OUT_ODD_TOTAL_UTIL\\,chip\\=?@ + hv_24x7@PM_ALINK6_OUT_EVEN_TOTAL_UTIL\\,chip\\=?@) / (hv_24x7@PM_ALINK6_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_ALINK6_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
+ "ScaleUnit": "1%",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "ALINK7_OUT_TOTAL_UTILIZATION",
+ "MetricExpr": "((hv_24x7@PM_ALINK7_OUT_ODD_TOTAL_UTIL\\,chip\\=?@ + hv_24x7@PM_ALINK7_OUT_EVEN_TOTAL_UTIL\\,chip\\=?@) / (hv_24x7@PM_ALINK7_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_ALINK7_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
+ "ScaleUnit": "1%",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "ALINK0_OUT_DATA_UTILIZATION",
+ "MetricExpr": "((hv_24x7@PM_ALINK0_OUT_ODD_DATA\\,chip\\=?@ + hv_24x7@PM_ALINK0_OUT_EVEN_DATA\\,chip\\=?@) / (hv_24x7@PM_ALINK0_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_ALINK0_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
+ "ScaleUnit": "1.063%",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "ALINK1_OUT_DATA_UTILIZATION",
+ "MetricExpr": "((hv_24x7@PM_ALINK1_OUT_ODD_DATA\\,chip\\=?@ + hv_24x7@PM_ALINK1_OUT_EVEN_DATA\\,chip\\=?@) / (hv_24x7@PM_ALINK1_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_ALINK1_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
+ "ScaleUnit": "1.063%",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "ALINK2_OUT_DATA_UTILIZATION",
+ "MetricExpr": "((hv_24x7@PM_ALINK2_OUT_ODD_DATA\\,chip\\=?@ + hv_24x7@PM_ALINK2_OUT_EVEN_DATA\\,chip\\=?@) / (hv_24x7@PM_ALINK2_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_ALINK2_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
+ "ScaleUnit": "1.063%",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "ALINK3_OUT_DATA_UTILIZATION",
+ "MetricExpr": "((hv_24x7@PM_ALINK3_OUT_ODD_DATA\\,chip\\=?@ + hv_24x7@PM_ALINK3_OUT_EVEN_DATA\\,chip\\=?@) / (hv_24x7@PM_ALINK3_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_ALINK3_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
+ "ScaleUnit": "1.063%",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "ALINK4_OUT_DATA_UTILIZATION",
+ "MetricExpr": "((hv_24x7@PM_ALINK4_OUT_ODD_DATA\\,chip\\=?@ + hv_24x7@PM_ALINK4_OUT_EVEN_DATA\\,chip\\=?@) / (hv_24x7@PM_ALINK4_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_ALINK4_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
+ "ScaleUnit": "1.063%",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "ALINK5_OUT_DATA_UTILIZATION",
+ "MetricExpr": "((hv_24x7@PM_ALINK5_OUT_ODD_DATA\\,chip\\=?@ + hv_24x7@PM_ALINK5_OUT_EVEN_DATA\\,chip\\=?@) / (hv_24x7@PM_ALINK5_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_ALINK5_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
+ "ScaleUnit": "1.063%",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "ALINK6_OUT_DATA_UTILIZATION",
+ "MetricExpr": "((hv_24x7@PM_ALINK6_OUT_ODD_DATA\\,chip\\=?@ + hv_24x7@PM_ALINK6_OUT_EVEN_DATA\\,chip\\=?@) / (hv_24x7@PM_ALINK6_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_ALINK6_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
+ "ScaleUnit": "1.063%",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "ALINK7_OUT_DATA_UTILIZATION",
+ "MetricExpr": "((hv_24x7@PM_ALINK7_OUT_ODD_DATA\\,chip\\=?@ + hv_24x7@PM_ALINK7_OUT_EVEN_DATA\\,chip\\=?@) / (hv_24x7@PM_ALINK7_OUT_ODD_AVLBL_CYCLES\\,chip\\=?@ + hv_24x7@PM_ALINK7_OUT_EVEN_AVLBL_CYCLES\\,chip\\=?@)) * 100",
+ "ScaleUnit": "1.063%",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "TOTAL_DATA_BANDWIDTH_TRANSFERRED_OVER_PB_PCI1",
+ "MetricExpr": "(hv_24x7@PM_PCI1_32B_INOUT\\,chip\\=?@)",
+ "ScaleUnit": "3.28e-2MB",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "TOTAL_DATA_BANDWIDTH_TRANSFERRED_OVER_PB_PCI0",
+ "MetricExpr": "(hv_24x7@PM_PCI0_32B_INOUT\\,chip\\=?@)",
+ "ScaleUnit": "3.28e-2MB",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "TOTAL_MCS_READ_BW_MC0_CHAN01",
+ "MetricExpr": "(hv_24x7@PM_MCS_128B_RD_DATA_BLOCKS_MC0_CHAN01\\,chip\\=?@)",
+ "ScaleUnit": "5.24e-1MB",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "TOTAL_MCS_READ_BW_MC1_CHAN01",
+ "MetricExpr": "(hv_24x7@PM_MCS_128B_RD_DATA_BLOCKS_MC1_CHAN01\\,chip\\=?@)",
+ "ScaleUnit": "5.24e-1MB",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "TOTAL_MCS_READ_BW_MC2_CHAN01",
+ "MetricExpr": "(hv_24x7@PM_MCS_128B_RD_DATA_BLOCKS_MC2_CHAN01\\,chip\\=?@)",
+ "ScaleUnit": "5.24e-1MB",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "TOTAL_MCS_READ_BW_MC3_CHAN01",
+ "MetricExpr": "(hv_24x7@PM_MCS_128B_RD_DATA_BLOCKS_MC3_CHAN01\\,chip\\=?@)",
+ "ScaleUnit": "5.24e-1MB",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "TOTAL_MCS_WRITE_BW_MC0_CHAN01",
+ "MetricExpr": "(hv_24x7@PM_MCS_64B_WR_DATA_BLOCKS_MC0_CHAN01\\,chip\\=?@)",
+ "ScaleUnit": "2.6e-1MB",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "TOTAL_MCS_WRITE_BW_MC1_CHAN01",
+ "MetricExpr": "(hv_24x7@PM_MCS_64B_WR_DATA_BLOCKS_MC1_CHAN01\\,chip\\=?@)",
+ "ScaleUnit": "2.6e-1MB",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "TOTAL_MCS_WRITE_BW_MC2_CHAN01",
+ "MetricExpr": "(hv_24x7@PM_MCS_64B_WR_DATA_BLOCKS_MC2_CHAN01\\,chip\\=?@)",
+ "ScaleUnit": "2.6e-1MB",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "TOTAL_MCS_WRITE_BW_MC3_CHAN01",
+ "MetricExpr": "(hv_24x7@PM_MCS_64B_WR_DATA_BLOCKS_MC3_CHAN01\\,chip\\=?@)",
+ "ScaleUnit": "2.6e-1MB",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "Memory_RD_BW_Chip",
+ "MetricExpr": "(hv_24x7@PM_MCS_128B_RD_DATA_BLOCKS_MC0_CHAN01\\,chip\\=?@ + hv_24x7@PM_MCS_128B_RD_DATA_BLOCKS_MC1_CHAN01\\,chip\\=?@ + hv_24x7@PM_MCS_128B_RD_DATA_BLOCKS_MC2_CHAN01\\,chip\\=?@ + hv_24x7@PM_MCS_128B_RD_DATA_BLOCKS_MC3_CHAN01\\,chip\\=?@)",
+ "MetricGroup": "Memory_BW",
+ "ScaleUnit": "5.24e-1MB",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "Memory_WR_BW_Chip",
+ "MetricExpr": "(hv_24x7@PM_MCS_64B_WR_DATA_BLOCKS_MC0_CHAN01\\,chip\\=?@ + hv_24x7@PM_MCS_64B_WR_DATA_BLOCKS_MC1_CHAN01\\,chip\\=?@ + hv_24x7@PM_MCS_64B_WR_DATA_BLOCKS_MC2_CHAN01\\,chip\\=?@ + hv_24x7@PM_MCS_64B_WR_DATA_BLOCKS_MC3_CHAN01\\,chip\\=?@ )",
+ "MetricGroup": "Memory_BW",
+ "ScaleUnit": "2.6e-1MB",
+ "AggregationMode": "PerChip"
+ },
+ {
+ "MetricName": "PowerBUS_Frequency",
+ "MetricExpr": "(hv_24x7@PM_PAU_CYC\\,chip\\=?@ )",
+ "ScaleUnit": "2.56e-7GHz",
+ "AggregationMode": "PerChip"
+ }
+]
--
2.31.1
^ permalink raw reply related
* [PATCH] powerpc/32s: Fix setup_{kuap/kuep}() on SMP
From: Christophe Leroy @ 2021-06-28 6:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
On SMP, setup_kup() is also called from start_secondary().
start_secondary() is not an __init function.
Remove the __init marker from setup_kuep() and and setup_kuap().
Reported-by: kernel test robot <lkp@intel.com>
Fixes: 86f46f343272 ("powerpc/32s: Initialise KUAP and KUEP in C").
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/mm/book3s32/kuap.c | 2 +-
arch/powerpc/mm/book3s32/kuep.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/book3s32/kuap.c b/arch/powerpc/mm/book3s32/kuap.c
index 9df6911b8fde..0f920f09af57 100644
--- a/arch/powerpc/mm/book3s32/kuap.c
+++ b/arch/powerpc/mm/book3s32/kuap.c
@@ -18,7 +18,7 @@ void kuap_unlock_all_ool(void)
}
EXPORT_SYMBOL(kuap_unlock_all_ool);
-void __init setup_kuap(bool disabled)
+void setup_kuap(bool disabled)
{
if (!disabled)
kuap_lock_all_ool();
diff --git a/arch/powerpc/mm/book3s32/kuep.c b/arch/powerpc/mm/book3s32/kuep.c
index 3f6eb6e23fca..c20733d6e02c 100644
--- a/arch/powerpc/mm/book3s32/kuep.c
+++ b/arch/powerpc/mm/book3s32/kuep.c
@@ -5,7 +5,7 @@
struct static_key_false disable_kuep_key;
-void __init setup_kuep(bool disabled)
+void setup_kuep(bool disabled)
{
if (!disabled)
kuep_lock();
--
2.25.0
^ permalink raw reply related
* [PATCH] powerpc/4xx: Fix setup_kuep() on SMP
From: Christophe Leroy @ 2021-06-28 6:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
On SMP, setup_kuep() is also called from start_secondary() since
commit 86f46f343272 ("powerpc/32s: Initialise KUAP and KUEP in C").
start_secondary() is not an __init function.
Remove the __init marker from setup_kuep() and bail out when
not caller on the first CPU as the work is already done.
Reported-by: kernel test robot <lkp@intel.com>
Fixes: 10248dcba120 ("powerpc/44x: Implement Kernel Userspace Exec Protection (KUEP)")
Fixes: 86f46f343272 ("powerpc/32s: Initialise KUAP and KUEP in C").
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/mm/nohash/44x.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/nohash/44x.c b/arch/powerpc/mm/nohash/44x.c
index 7da6d1e9fc9b..20c18bd5b9a0 100644
--- a/arch/powerpc/mm/nohash/44x.c
+++ b/arch/powerpc/mm/nohash/44x.c
@@ -241,8 +241,11 @@ void __init mmu_init_secondary(int cpu)
#endif /* CONFIG_SMP */
#ifdef CONFIG_PPC_KUEP
-void __init setup_kuep(bool disabled)
+void setup_kuep(bool disabled)
{
+ if (smp_processor_id() != boot_cpuid)
+ return;
+
if (disabled)
patch_instruction_site(&patch__tlb_44x_kuep, ppc_inst(PPC_RAW_NOP()));
else
--
2.25.0
^ permalink raw reply related
* Re: [PATCH] perf script python: Fix buffer size to report iregs in perf script
From: Nageswara Sastry @ 2021-06-28 7:15 UTC (permalink / raw)
To: Kajol Jain, acme
Cc: ravi.bangoria, atrajeev, linuxppc-dev, linux-kernel,
linux-perf-users, maddy, pc, jolsa
In-Reply-To: <20210628062341.155839-1-kjain@linux.ibm.com>
Tested by creating perf-script.py using perf script
and priting the iregs. Seen more values with this patch.
Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com>
On 28/06/21 11:53 am, Kajol Jain wrote:
> Commit 48a1f565261d ("perf script python: Add more PMU fields
> to event handler dict") added functionality to report fields like
> weight, iregs, uregs etc via perf report.
> That commit predefined buffer size to 512 bytes to print those fields.
>
> But incase of powerpc, since we added extended regs support
> in commits:
>
> Commit 068aeea3773a ("perf powerpc: Support exposing Performance Monitor
> Counter SPRs as part of extended regs")
> Commit d735599a069f ("powerpc/perf: Add extended regs support for
> power10 platform")
>
> Now iregs can carry more bytes of data and this predefined buffer size
> can result to data loss in perf script output.
>
> Patch resolve this issue by making buffer size dynamic based on number
> of registers needed to print. It also changed return type for function
> "regs_map" from int to void, as the return value is not being used by
> the caller function "set_regs_in_dict".
>
> Fixes: 068aeea3773a ("perf powerpc: Support exposing Performance Monitor
> Counter SPRs as part of extended regs")
> Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
> ---
> .../util/scripting-engines/trace-event-python.c | 17 ++++++++++++-----
> 1 file changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/tools/perf/util/scripting-engines/trace-event-python.c b/tools/perf/util/scripting-engines/trace-event-python.c
> index 4e4aa4c97ac5..c8c9706b4643 100644
> --- a/tools/perf/util/scripting-engines/trace-event-python.c
> +++ b/tools/perf/util/scripting-engines/trace-event-python.c
> @@ -687,7 +687,7 @@ static void set_sample_datasrc_in_dict(PyObject *dict,
> _PyUnicode_FromString(decode));
> }
>
> -static int regs_map(struct regs_dump *regs, uint64_t mask, char *bf, int size)
> +static void regs_map(struct regs_dump *regs, uint64_t mask, char *bf, int size)
> {
> unsigned int i = 0, r;
> int printed = 0;
> @@ -695,7 +695,7 @@ static int regs_map(struct regs_dump *regs, uint64_t mask, char *bf, int size)
> bf[0] = 0;
>
> if (!regs || !regs->regs)
> - return 0;
> + return;
>
> for_each_set_bit(r, (unsigned long *) &mask, sizeof(mask) * 8) {
> u64 val = regs->regs[i++];
> @@ -704,8 +704,6 @@ static int regs_map(struct regs_dump *regs, uint64_t mask, char *bf, int size)
> "%5s:0x%" PRIx64 " ",
> perf_reg_name(r), val);
> }
> -
> - return printed;
> }
>
> static void set_regs_in_dict(PyObject *dict,
> @@ -713,7 +711,16 @@ static void set_regs_in_dict(PyObject *dict,
> struct evsel *evsel)
> {
> struct perf_event_attr *attr = &evsel->core.attr;
> - char bf[512];
> +
> + /*
> + * Here value 28 is a constant size which can be used to print
> + * one register value and its corresponds to:
> + * 16 chars is to specify 64 bit register in hexadecimal.
> + * 2 chars is for appending "0x" to the hexadecimal value and
> + * 10 chars is for register name.
> + */
> + int size = __sw_hweight64(attr->sample_regs_intr) * 28;
> + char bf[size];
>
> regs_map(&sample->intr_regs, attr->sample_regs_intr, bf, sizeof(bf));
>
>
--
Thanks and Regards
R.Nageswara Sastry
^ permalink raw reply
* [RFC] fpga: dfl: fme: Fix cpu hotplug code
From: Kajol Jain @ 2021-06-28 7:15 UTC (permalink / raw)
To: will, hao.wu, mark.rutland
Cc: maddy, luwei.kang, rnsastry, trix, linux-fpga, linux-kernel,
atrajeev, mdf, kjain, linuxppc-dev, yilun.xu
Commit 724142f8c42a ("fpga: dfl: fme: add performance
reporting support") added performance reporting support
for FPGA management engine via perf.
It also added cpu hotplug feature but it didn't add
pmu migration call in cpu offline function.
This can create an issue incase the current designated
cpu being used to collect fme pmu data got offline,
as based on current code we are not migrating fme pmu to
new target cpu. Because of that perf will still try to
fetch data from that offline cpu and hence we will not
get counter data.
Patch fixed this issue by adding pmu_migrate_context call
in fme_perf_offline_cpu function.
Fixes: 724142f8c42a ("fpga: dfl: fme: add performance reporting support")
Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
---
drivers/fpga/dfl-fme-perf.c | 4 ++++
1 file changed, 4 insertions(+)
---
- This fix patch is not tested (as I don't have required environment).
But issue mentioned in the commit msg can be re-created, by starting any
fme_perf event and while its still running, offline current designated
cpu pointed by cpumask file. Since current code didn't migrating pmu,
perf gonna try getting counts from that offlined cpu and hence we will
not get event data.
---
diff --git a/drivers/fpga/dfl-fme-perf.c b/drivers/fpga/dfl-fme-perf.c
index 4299145ef347..b9a54583e505 100644
--- a/drivers/fpga/dfl-fme-perf.c
+++ b/drivers/fpga/dfl-fme-perf.c
@@ -953,6 +953,10 @@ static int fme_perf_offline_cpu(unsigned int cpu, struct hlist_node *node)
return 0;
priv->cpu = target;
+
+ /* Migrate fme_perf pmu events to the new target cpu */
+ perf_pmu_migrate_context(&priv->pmu, cpu, target);
+
return 0;
}
--
2.31.1
^ permalink raw reply related
* Re: [PATCH v4 7/7] powerpc/pseries: Add support for FORM2 associativity
From: David Gibson @ 2021-06-28 6:18 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: Nathan Lynch, nvdimm, Daniel Henrique Barboza, dan.j.williams,
linuxppc-dev
In-Reply-To: <87eecrllm5.fsf@linux.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 32246 bytes --]
On Thu, Jun 24, 2021 at 01:50:34PM +0530, Aneesh Kumar K.V wrote:
> David Gibson <david@gibson.dropbear.id.au> writes:
>
> > On Thu, Jun 17, 2021 at 10:21:05PM +0530, Aneesh Kumar K.V wrote:
> >> PAPR interface currently supports two different ways of communicating resource
> >> grouping details to the OS. These are referred to as Form 0 and Form 1
> >> associativity grouping. Form 0 is the older format and is now considered
> >> deprecated. This patch adds another resource grouping named FORM2.
> >>
> >> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
> >> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> >> ---
> >> Documentation/powerpc/associativity.rst | 135 ++++++++++++++++++++
> >> arch/powerpc/include/asm/firmware.h | 3 +-
> >> arch/powerpc/include/asm/prom.h | 1 +
> >> arch/powerpc/kernel/prom_init.c | 3 +-
> >> arch/powerpc/mm/numa.c | 149 +++++++++++++++++++++-
> >> arch/powerpc/platforms/pseries/firmware.c | 1 +
> >> 6 files changed, 286 insertions(+), 6 deletions(-)
> >> create mode 100644 Documentation/powerpc/associativity.rst
> >>
> >> diff --git a/Documentation/powerpc/associativity.rst b/Documentation/powerpc/associativity.rst
> >> new file mode 100644
> >> index 000000000000..93be604ac54d
> >> --- /dev/null
> >> +++ b/Documentation/powerpc/associativity.rst
> >> @@ -0,0 +1,135 @@
> >> +============================
> >> +NUMA resource associativity
> >> +=============================
> >> +
> >> +Associativity represents the groupings of the various platform resources into
> >> +domains of substantially similar mean performance relative to resources outside
> >> +of that domain. Resources subsets of a given domain that exhibit better
> >> +performance relative to each other than relative to other resources subsets
> >> +are represented as being members of a sub-grouping domain. This performance
> >> +characteristic is presented in terms of NUMA node distance within the Linux kernel.
> >> +From the platform view, these groups are also referred to as domains.
> >> +
> >> +PAPR interface currently supports different ways of communicating these resource
> >> +grouping details to the OS. These are referred to as Form 0, Form 1 and Form2
> >> +associativity grouping. Form 0 is the older format and is now considered deprecated.
> >> +
> >> +Hypervisor indicates the type/form of associativity used via "ibm,arcitecture-vec-5 property".
> >> +Bit 0 of byte 5 in the "ibm,architecture-vec-5" property indicates usage of Form 0 or Form 1.
> >> +A value of 1 indicates the usage of Form 1 associativity. For Form 2 associativity
> >> +bit 2 of byte 5 in the "ibm,architecture-vec-5" property is used.
> >> +
> >> +Form 0
> >> +-----
> >> +Form 0 associativity supports only two NUMA distance (LOCAL and REMOTE).
> >> +
> >> +Form 1
> >> +-----
> >> +With Form 1 a combination of ibm,associativity-reference-points and ibm,associativity
> >> +device tree properties are used to determine the NUMA distance between resource groups/domains.
> >> +
> >> +The “ibm,associativity” property contains one or more lists of numbers (domainID)
> >> +representing the resource’s platform grouping domains.
> >> +
> >> +The “ibm,associativity-reference-points” property contains one or more list of numbers
> >> +(domainID index) that represents the 1 based ordinal in the associativity lists.
> >> +The list of domainID index represnets increasing hierachy of
> >> resource grouping.
> >
> > Typo "represnets". Also s/hierachy/hierarchy/
> >
> >> +
> >> +ex:
> >> +{ primary domainID index, secondary domainID index, tertiary domainID index.. }
> >
> >> +Linux kernel uses the domainID at the primary domainID index as the NUMA node id.
> >> +Linux kernel computes NUMA distance between two domains by recursively comparing
> >> +if they belong to the same higher-level domains. For mismatch at every higher
> >> +level of the resource group, the kernel doubles the NUMA distance between the
> >> +comparing domains.
> >
> > The Form1 description is still kinda confusing, but I don't really
> > care. Form1 *is* confusing, it's Form2 that I hope will be clearer.
> >
> >> +
> >> +Form 2
> >> +-------
> >> +Form 2 associativity format adds separate device tree properties representing NUMA node distance
> >> +thereby making the node distance computation flexible. Form 2 also allows flexible primary
> >> +domain numbering. With numa distance computation now detached from the index value of
> >> +"ibm,associativity" property, Form 2 allows a large number of primary domain ids at the
> >> +same domainID index representing resource groups of different performance/latency characteristics.
> >
> > So, see you've removed the special handling of secondary IDs for pmem
> > - big improvement, thanks. IIUC, in this revised version, for Form2
> > there's really no reason for ibm,associativity-reference-points to
> > have >1 entry. Is that right?
> >
> > In Form2 everything revolves around the primary domain ID - so much
> > that I suggest we come up with a short name for it. How about just
> > "node id" since that's how Linux uses it.
>
> We don't really refer primary domain ID in rest of FORM2 details. We
> do refer the entries as domainID.
Right, which is unnecessarily confusing, because primary domain ID is
going to be the only one that matters in practice.
> Is renaming domainID to NUMA
> node id better?
>
> >
> >> +Hypervisor indicates the usage of FORM2 associativity using bit 2 of byte 5 in the
> >> +"ibm,architecture-vec-5" property.
> >> +
> >> +"ibm,numa-lookup-index-table" property contains one or more list numbers representing
> >> +the domainIDs present in the system. The offset of the domainID in this property is considered
> >> +the domainID index.
> >
> > The lookup-index-table is all about compactifying the representation
> > of the distance matrix. Because node ids are sparse, the matrix of
> > distances is also effectively sparse. You don't want to have a huge
> > matrix in the DT with mostly meaningless entries, so you use the
> > lookup table to compact the node ids.
> >
> > It's a bit confusing though, because you now have two representations
> > of exactly the same information the "full" node id (== primary
> > domainID) and the "short" node id (==domainID lookup table offset).
> >
> > I can see three ways to clarify this:
> >
> > A) Give the short node id an explicit name rather than difficult to
> > parse "domainID index" or "domainID offset" which gets easily
> > muddled with other uses of index and offset. Use that name
> > throughout.
>
> I dopped the domainID index and started referring to that as domain
> distance offset.
Better, since it's not ambiguous. Still kinda long and awkward.
> > B) Eliminate the short ID entirely, and use an explicit sparse
> > matrix representation for the distance table e.g. a list of
> > (nodeA, nodeB, distance) tuples
> >
> > That does have the disadvantage that it's not structurally
> > guaranteed that you have entries for every pair of "active" node
> > ids.
>
> Other hypervisor would want to have a large possible domainID value and
> mostly want to publish the full topology details during boot. Using the
> above format makes a 16 node config have large "ibm,numa-distance-table"
> property.
It'd be about 3kiB, yes? That's fairly large, but not ludicrously
large, so does that matter?
> > C) Eliminate the "long ID" entirely. In the Form2 world, is there
> > actually any point allowing sparse node ids? In this case you'd
> > have the node id read from associativity and use that directly to
> > index the distance table
>
> Yes, other hypervisor would like to partition the domain ID space for
> different resources.
Is that really a hard requirement on the dt format though? The
hypervisor could always have its own internal lookup table between
long and short forms.
> >> +prop-encoded-array: The number N of the domainIDs encoded as with encode-int, followed by
> >> +N domainID encoded as with encode-int
> >> +
> >> +For ex:
> >> +ibm,numa-lookup-index-table = {4, 0, 8, 250, 252}, domainID index
> >> for domainID 8 is 1.
> >
> > As noted "domainID index" is confusing here, because it's different
> > from the "domainID index" values in reference-points.
> >
> >> +
> >> +"ibm,numa-distance-table" property contains one or more list of numbers representing the NUMA
> >> +distance between resource groups/domains present in the system.
> >> +
> >> +prop-encoded-array: The number N of the distance values encoded as with encode-int, followed by
> >> +N distance values encoded as with encode-bytes. The max distance value we could encode is 255.
> >
> > The N here always has to be the square of the N in the
> > lookup-index-table, yes? In which case do we actually need to include
> > it?
>
> most of PAPR device tree property follows the pattern {N,....
> Nelements}. This follows the same pattern.
Many do, yes, but in many of those cases reading the N is actually
useful. It's impossible to interpret this table if you don't already
know the number of nodes and if the length of the distance doesn't
match that, there's no reasonable fallback interpretation.
> >> +For ex:
> >> +ibm,numa-lookup-index-table = {3, 0, 8, 40}
> >> +ibm,numa-distance-table = {9, 10, 20, 80, 20, 10, 160, 80, 160, 10}
> >> +
> >> + | 0 8 40
> >> +--|------------
> >> + |
> >> +0 | 10 20 80
> >> + |
> >> +8 | 20 10 160
> >> + |
> >> +40| 80 160 10
> >> +
> >> +
> >> +"ibm,associativity" property for resources in node 0, 8 and 40
> >> +
> >> +{ 3, 6, 7, 0 }
> >> +{ 3, 6, 9, 8 }
> >> +{ 3, 6, 7, 40}
> >> +
> >> +With "ibm,associativity-reference-points" { 0x3 }
> >> +
> >> +Each resource (drcIndex) now also supports additional optional device tree properties.
> >> +These properties are marked optional because the platform can choose not to export
> >> +them and provide the system topology details using the earlier defined device tree
> >> +properties alone. The optional device tree properties are used when adding new resources
> >> +(DLPAR) and when the platform didn't provide the topology details of the domain which
> >> +contains the newly added resource during boot.
> >
> > In what circumstances would you envisage a hot-add creating a new NUMA
> > node, as opposed to adding resources to an existing (possibly empty)
> > node? Do you need any provision for removing NUMA nodes again?
>
> Both Qemu and PowerVM don't intend to use this at this point. Both will
> provide the full possible NUMA node details during boot. But I was not
> sure whether we really need to restrict the possibility of a new
> resource being added. This can be true in case of new memory devices
> that gets hotplugged in the latency of the device is such that we never
> expressed that in the distance table during boot.
Hm, ok. Can we just leave it out of the spec for now and add it in
when/if a hypervisor needs it?
> >> +"ibm,numa-lookup-index" property contains a number representing the domainID index to be used
> >> +when building the NUMA distance of the numa node to which this resource belongs. This can
> >> +be looked at as the index at which this new domainID would have appeared in
> >> +"ibm,numa-lookup-index-table" if the domain was present during boot. The domainID
> >
> > Again, confusing use of "index" where it's used both for offsets in
> > ibm,associativity properties and for offsets in ibm,numa-lookup-index-table
>
> I guess we can drop the ibm,numa-lookuup-index and state that the
> number of distance element in "ibm,numa-distance" suggest the index at
> which this NUMA node should appear for compuring the distance details.
I don't really follow what you're saying there.
> >> +of the new resource can be obtained from the existing "ibm,associativity" property. This
> >> +can be used to build distance information of a newly onlined NUMA node via DLPAR operation.
> >> +The value is 1 based array index value.
> >> +
> >> +prop-encoded-array: An integer encoded as with encode-int specifying the domainID index
> >> +
> >> +"ibm,numa-distance" property contains one or more list of numbers presenting the NUMA distance
> >> +from this resource domain to other resources.
> >> +
> >> +prop-encoded-array: The number N of the distance values encoded as with encode-int, followed by
> >> +N distance values encoded as with encode-bytes. The max distance value we could encode is 255.
> >
> > Again, does N have to equal 2 * (existing number of nodes + 1)? If so
> > you should say so, if not you should specify how incomplete
> > information is interpreted.
> >
> >> +For ex:
> >> +ibm,associativity = { 4, 5, 10, 50}
> >> +ibm,numa-lookup-index = { 4 }
> >> +ibm,numa-distance = {8, 160, 255, 80, 10, 160, 255, 80, 10}
> >> +
> >> +resulting in a new toplogy as below.
> >> + | 0 8 40 50
> >> +--|------------------
> >> + |
> >> +0 | 10 20 80 160
> >> + |
> >> +8 | 20 10 160 255
> >> + |
> >> +40| 80 160 10 80
> >> + |
> >> +50| 160 255 80 10
> >> +
>
> Here is the relevant updated part of the doc.
>
> Form 2 associativity format adds separate device tree properties representing NUMA node distance
> thereby making the node distance computation flexible. Form 2 also allows flexible primary
> domain numbering. With numa distance computation now detached from the index value in
> "ibm,associativity-reference-points" property, Form 2 allows a large number of primary domain
> ids at the same domainID index representing resource groups of different performance/latency
> characteristics.
>
> Hypervisor indicates the usage of FORM2 associativity using bit 2 of byte 5 in the
> "ibm,architecture-vec-5" property.
>
> "ibm,numa-lookup-index-table" property contains one or more list numbers representing
s/one or more list numbers/a list of one or more numbers/
> the domainIDs present in the system. The offset of the domainID in this property is
> used as an index while computing numa distance information via "ibm,numa-distance-table".
>
> prop-encoded-array: The number N of the domainIDs encoded as with encode-int, followed by
> N domainID encoded as with encode-int
>
> For ex:
> "ibm,numa-lookup-index-table" = {4, 0, 8, 250, 252}. Offset of domainID 8 (2) is used when
> computing the distance of domain 8 from other domains present in the system. For rest of
> this document this offset will be referred to as domain distance offset.
>
> "ibm,numa-distance-table" property contains one or more list of numbers representing the NUMA
> distance between resource groups/domains present in the system.
>
> prop-encoded-array: The number N of the distance values encoded as with encode-int, followed by
> N distance values encoded as with encode-bytes. The max distance value we could encode is 255.
If you insist on retaining the N here, at least explicitly state that
it must be equal to m^2, where m is the number of nodes in numa-lookup-index-table.
> For ex:
> ibm,numa-lookup-index-table = {3, 0, 8, 40}
> ibm,numa-distance-table = {9, 10, 20, 80, 20, 10, 160, 80, 160, 10}
>
> | 0 8 40
> --|------------
> |
> 0 | 10 20 80
> |
> 8 | 20 10 160
> |
> 40| 80 160 10
>
> A possible "ibm,associativity" property for resources in node 0, 8 and 40
>
> { 3, 6, 7, 0 }
> { 3, 6, 9, 8 }
> { 3, 6, 7, 40}
>
> With "ibm,associativity-reference-points" { 0x3 }
>
> "ibm,lookup-index-table" helps in having a compact representation of distance matrix.
> Since domainID can be sparse, the matrix of distances can also be effectively sparse.
> With "ibm,lookup-index-table" we are able to achieve a compact representation of
> distance information.
>
> Each resource (drcIndex) now also supports additional optional device tree properties.
> These properties are marked optional because the platform can choose not to export
> them and provide the system topology details using the earlier defined device tree
> properties alone. The optional device tree properties are used when adding new resources
> (DLPAR) and when the platform didn't provide the topology details of the domain which
> contains the newly added resource during boot.
>
> "ibm,numa-distance" property contains one or more list of numbers presenting the NUMA distance
> from this resource domain to other resources.
>
> prop-encoded-array: The number N of the distance values encoded as with encode-int, followed by
> N distance values encoded as with encode-bytes. The max distance value we could encode is 255.
> If the system currently has 3 domains and a DLPAR operation is adding one additional
> domain, "ibm,numa-distance" property should have 2 * (3 + 1) = 8 elements as shown below.
> In other words the domain distance offset value for the newly added domain is number of
> distance value elements in the "ibm,numa-distance" property divided by 2.
You need to spell out the distinction between the two halves of the
property - which one adds a row to numa-distance-table, and which one
adds a column.
> >> diff --git a/arch/powerpc/include/asm/firmware.h b/arch/powerpc/include/asm/firmware.h
> >> index 60b631161360..97a3bd9ffeb9 100644
> >> --- a/arch/powerpc/include/asm/firmware.h
> >> +++ b/arch/powerpc/include/asm/firmware.h
> >> @@ -53,6 +53,7 @@
> >> #define FW_FEATURE_ULTRAVISOR ASM_CONST(0x0000004000000000)
> >> #define FW_FEATURE_STUFF_TCE ASM_CONST(0x0000008000000000)
> >> #define FW_FEATURE_RPT_INVALIDATE ASM_CONST(0x0000010000000000)
> >> +#define FW_FEATURE_FORM2_AFFINITY ASM_CONST(0x0000020000000000)
> >>
> >> #ifndef __ASSEMBLY__
> >>
> >> @@ -73,7 +74,7 @@ enum {
> >> FW_FEATURE_HPT_RESIZE | FW_FEATURE_DRMEM_V2 |
> >> FW_FEATURE_DRC_INFO | FW_FEATURE_BLOCK_REMOVE |
> >> FW_FEATURE_PAPR_SCM | FW_FEATURE_ULTRAVISOR |
> >> - FW_FEATURE_RPT_INVALIDATE,
> >> + FW_FEATURE_RPT_INVALIDATE | FW_FEATURE_FORM2_AFFINITY,
> >> FW_FEATURE_PSERIES_ALWAYS = 0,
> >> FW_FEATURE_POWERNV_POSSIBLE = FW_FEATURE_OPAL | FW_FEATURE_ULTRAVISOR,
> >> FW_FEATURE_POWERNV_ALWAYS = 0,
> >> diff --git a/arch/powerpc/include/asm/prom.h b/arch/powerpc/include/asm/prom.h
> >> index df9fec9d232c..5c80152e8f18 100644
> >> --- a/arch/powerpc/include/asm/prom.h
> >> +++ b/arch/powerpc/include/asm/prom.h
> >> @@ -149,6 +149,7 @@ extern int of_read_drc_info_cell(struct property **prop,
> >> #define OV5_XCMO 0x0440 /* Page Coalescing */
> >> #define OV5_FORM1_AFFINITY 0x0580 /* FORM1 NUMA affinity */
> >> #define OV5_PRRN 0x0540 /* Platform Resource Reassignment */
> >> +#define OV5_FORM2_AFFINITY 0x0520 /* Form2 NUMA affinity */
> >> #define OV5_HP_EVT 0x0604 /* Hot Plug Event support */
> >> #define OV5_RESIZE_HPT 0x0601 /* Hash Page Table resizing */
> >> #define OV5_PFO_HW_RNG 0x1180 /* PFO Random Number Generator */
> >> diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
> >> index 64b9593038a7..496fdac54c29 100644
> >> --- a/arch/powerpc/kernel/prom_init.c
> >> +++ b/arch/powerpc/kernel/prom_init.c
> >> @@ -1070,7 +1070,8 @@ static const struct ibm_arch_vec ibm_architecture_vec_template __initconst = {
> >> #else
> >> 0,
> >> #endif
> >> - .associativity = OV5_FEAT(OV5_FORM1_AFFINITY) | OV5_FEAT(OV5_PRRN),
> >> + .associativity = OV5_FEAT(OV5_FORM1_AFFINITY) | OV5_FEAT(OV5_PRRN) |
> >> + OV5_FEAT(OV5_FORM2_AFFINITY),
> >> .bin_opts = OV5_FEAT(OV5_RESIZE_HPT) | OV5_FEAT(OV5_HP_EVT),
> >> .micro_checkpoint = 0,
> >> .reserved0 = 0,
> >> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
> >> index d32729f235b8..5a7d94960fb7 100644
> >> --- a/arch/powerpc/mm/numa.c
> >> +++ b/arch/powerpc/mm/numa.c
> >> @@ -56,12 +56,17 @@ static int n_mem_addr_cells, n_mem_size_cells;
> >>
> >> #define FORM0_AFFINITY 0
> >> #define FORM1_AFFINITY 1
> >> +#define FORM2_AFFINITY 2
> >> static int affinity_form;
> >>
> >> #define MAX_DISTANCE_REF_POINTS 4
> >> static int max_associativity_domain_index;
> >> static const __be32 *distance_ref_points;
> >> static int distance_lookup_table[MAX_NUMNODES][MAX_DISTANCE_REF_POINTS];
> >> +static int numa_distance_table[MAX_NUMNODES][MAX_NUMNODES] = {
> >> + [0 ... MAX_NUMNODES - 1] = { [0 ... MAX_NUMNODES - 1] = -1 }
> >> +};
> >> +static int numa_id_index_table[MAX_NUMNODES];
> >>
> >> /*
> >> * Allocate node_to_cpumask_map based on number of available nodes
> >> @@ -166,6 +171,27 @@ static void unmap_cpu_from_node(unsigned long cpu)
> >> }
> >> #endif /* CONFIG_HOTPLUG_CPU || CONFIG_PPC_SPLPAR */
> >>
> >> +/*
> >> + * With FORM2 if we are not using logical domain ids, we will find
> >> + * both primary and seconday domains with same value. Hence always
> >> + * start comparison from secondary domains
> >
> >
> > IIUC, in this new draft, secondary domains are no longer a meaningful
> > thing in Form2, so this comment and code seem outdated.
>
> This needed fixup. With FORM2 our associativity array can be just one
> element. I fixed up as below.
>
> static int __cpu_form2_distance(__be32 *cpu1_assoc, __be32 *cpu2_assoc)
> {
> int node1, node2;
> int dist = 0;
>
> node1 = associativity_to_nid(cpu1_assoc);
> node2 = associativity_to_nid(cpu2_assoc);
>
> dist = numa_distance_table[node1][node2];
> if (dist == LOCAL_DISTANCE)
> return 0;
> else if (dist == REMOTE_DISTANCE)
> return 1;
> else
> return 2;
> }
>
> also renamed cpu_distance to cpu_relative_distance.
>
>
> >> + */
> >> +static int __cpu_form2_distance(__be32 *cpu1_assoc, __be32 *cpu2_assoc)
> >> +{
> >> + int dist = 0;
> >> +
> >> + int i, index;
> >> +
> >> + for (i = 1; i < max_associativity_domain_index; i++) {
> >> + index = be32_to_cpu(distance_ref_points[i]);
> >> + if (cpu1_assoc[index] == cpu2_assoc[index])
> >> + break;
> >> + dist++;
> >> + }
> >> +
> >> + return dist;
> >> +}
> >> +
> >> static int __cpu_form1_distance(__be32 *cpu1_assoc, __be32 *cpu2_assoc)
> >> {
> >> int dist = 0;
> >> @@ -178,7 +204,6 @@ static int __cpu_form1_distance(__be32 *cpu1_assoc, __be32 *cpu2_assoc)
> >> break;
> >> dist++;
> >> }
> >> -
> >> return dist;
> >> }
> >>
> >> @@ -186,8 +211,9 @@ int cpu_distance(__be32 *cpu1_assoc, __be32 *cpu2_assoc)
> >> {
> >> /* We should not get called with FORM0 */
> >> VM_WARN_ON(affinity_form == FORM0_AFFINITY);
> >> -
> >> - return __cpu_form1_distance(cpu1_assoc, cpu2_assoc);
> >> + if (affinity_form == FORM1_AFFINITY)
> >> + return __cpu_form1_distance(cpu1_assoc, cpu2_assoc);
> >> + return __cpu_form2_distance(cpu1_assoc, cpu2_assoc);
> >> }
> >>
> >> /* must hold reference to node during call */
> >> @@ -201,7 +227,9 @@ int __node_distance(int a, int b)
> >> int i;
> >> int distance = LOCAL_DISTANCE;
> >>
> >> - if (affinity_form == FORM0_AFFINITY)
> >> + if (affinity_form == FORM2_AFFINITY)
> >> + return numa_distance_table[a][b];
> >> + else if (affinity_form == FORM0_AFFINITY)
> >> return ((a == b) ? LOCAL_DISTANCE : REMOTE_DISTANCE);
> >>
> >> for (i = 0; i < max_associativity_domain_index; i++) {
> >> @@ -303,15 +331,116 @@ static void initialize_form1_numa_distance(struct device_node *node)
> >>
> >> /*
> >> * Used to update distance information w.r.t newly added node.
> >> + * ibm,numa-lookup-index -> 4
> >> + * ibm,numa-distance -> {5, 20, 40, 60, 80, 10 }
> >> */
> >> void update_numa_distance(struct device_node *node)
> >> {
> >> + int i, nid, other_nid, other_nid_index = 0;
> >> + const __be32 *numa_indexp;
> >> + const __u8 *numa_distancep;
> >> + int numa_index, max_numa_index, numa_distance;
> >> +
> >> if (affinity_form == FORM0_AFFINITY)
> >> return;
> >> else if (affinity_form == FORM1_AFFINITY) {
> >> initialize_form1_numa_distance(node);
> >> return;
> >> }
> >> + /* FORM2 affinity */
> >> +
> >> + nid = of_node_to_nid_single(node);
> >> + if (nid == NUMA_NO_NODE)
> >> + return;
> >> +
> >> + /* Already initialized */
> >> + if (numa_distance_table[nid][nid] != -1)
> >
> > IIUC, this should exactly correspond to the case where the new
> > resource lies in an existing NUMA node, yes?
>
> yes.
>
> >
> >> + return;
> >> + /*
> >> + * update node distance if not already populated.
> >> + */
> >> + numa_distancep = of_get_property(node, "ibm,numa-distance", NULL);
> >> + if (!numa_distancep)
> >> + return;
> >> +
> >> + numa_indexp = of_get_property(node, "ibm,numa-lookup-index", NULL);
> >> + if (!numa_indexp)
> >> + return;
> >> +
> >> + numa_index = of_read_number(numa_indexp, 1);
> >> + /*
> >> + * update the numa_id_index_table. Device tree look at index table as
> >> + * 1 based array indexing.
> >> + */
> >> + numa_id_index_table[numa_index - 1] = nid;
> >> +
> >> + max_numa_index = of_read_number((const __be32 *)numa_distancep, 1);
> >> + VM_WARN_ON(max_numa_index != 2 * numa_index);
> >
> > You WARN_ON(), but you don't actually bail out to avoid indexing past
> > the end of the property below.
> >
> > AFAICT none of this really works unless numa_index == (previous number
> > of numa nodes + 1), which makes all the use of these different
> > variables kind of confusing. If you had a variable that you just set
> > equal to the new number of numa nodes (previous number plus the one
> > being added), then I think you can replace all numa_index and
> > max_numa_index references with that and it will be clearer.
>
> I rewrote that as below.
>
> numa_distancep = of_get_property(node, "ibm,numa-distance", NULL);
> if (!numa_distancep)
> return;
>
> max_dist_element = of_read_number((const __be32 *)numa_distancep, 1);
>
> numa_id_index = max_dist_element >> 1;
You already know the existing number of NUMA nodes, so it seems
clearer to me to alidate the new property against that, rather than
trying to parse it out of the new property.
> /*
> * update the numa_id_index_table. Device tree look at index table as
> * 1 based array indexing.
> */
> if (numa_id_index_table[numa_id_index - 1] != -1) {
> WARN(1, "Wrong NUMA distance information\n");
> return;
> }
I believe
if (WARN_ON(...))
return;
is idiomatic.
> numa_id_index_table[numa_id_index - 1] = nid;
>
> /* Skip the size which is encoded int */
> numa_distancep += sizeof(__be32);
Is numa_distancep a u32 pointer, or a char pointer? If it's a u32
pointer then adding sizeof(__be32) rather than 1 is incorrect here.
> /*
> * First fill the distance information from other node to this node.
> */
> distance_index = 0;
> for (i = 0; i < numa_id_index; i++) {
> numa_distance = numa_distancep[distance_index++];
.. but if it's a char pointer then this looks wrong.
> other_nid = numa_id_index_table[i];
> if (other_nid == NUMA_NO_NODE)
> continue;
> numa_distance_table[other_nid][nid] = numa_distance;
> }
>
> for (i = 0; i < numa_id_index; i++) {
> numa_distance = numa_distancep[distance_index++];
I'd just compute the offset from i here, rather than having another
variable to track.
> other_nid = numa_id_index_table[i];
> if (other_nid == NUMA_NO_NODE)
> continue;
> numa_distance_table[nid][other_nid] = numa_distance;
> }
> }
>
>
> >
> >
> >> + /* Skip the size which is encoded int */
> >> + numa_distancep += sizeof(__be32);
> >> +
> >> + /*
> >> + * First fill the distance information from other node to this node.
> >> + */
> >> + other_nid_index = 0;
> >> + for (i = 0; i < numa_index; i++) {
> >> + numa_distance = numa_distancep[i];
> >> + other_nid = numa_id_index_table[other_nid_index++];
> >> + numa_distance_table[other_nid][nid] = numa_distance;
> >> + }
> >> +
> >> + other_nid_index = 0;
> >> + for (; i < max_numa_index; i++) {
> >
> > Again, splitting this loop and carrying i over seems a confusing way
> > to code this. It's basically two loops of N, one writing a row of the
> > distance matrix, one writing a column (other_nid will even go through
> > the same values in each loop).
>
> Fixed
>
> >
> >> + numa_distance = numa_distancep[i];
> >> + other_nid = numa_id_index_table[other_nid_index++];
> >> + numa_distance_table[nid][other_nid] = numa_distance;
> >> + }
> >> +}
> >> +
> >> +/*
> >> + * ibm,numa-lookup-index-table= {N, domainid1, domainid2, ..... domainidN}
> >> + * ibm,numa-distance-table = { N, 1, 2, 4, 5, 1, 6, .... N elements}
> >> + */
> >> +static void initialize_form2_numa_distance_lookup_table(struct device_node *root)
> >> +{
> >> + const __u8 *numa_dist_table;
> >> + const __be32 *numa_lookup_index;
> >> + int numa_dist_table_length;
> >> + int max_numa_index, distance_index;
> >> + int i, curr_row = 0, curr_column = 0;
> >> +
> >> + numa_lookup_index = of_get_property(root, "ibm,numa-lookup-index-table", NULL);
> >> + max_numa_index = of_read_number(&numa_lookup_index[0], 1);
> >
> > max_numa_index here has a different meaning to max_numa_index in the
> > previous function, which is pointlessly confusing.
> >
> >> + /* first element of the array is the size and is encode-int */
> >> + numa_dist_table = of_get_property(root, "ibm,numa-distance-table", NULL);
> >> + numa_dist_table_length = of_read_number((const __be32 *)&numa_dist_table[0], 1);
> >> + /* Skip the size which is encoded int */
> >> + numa_dist_table += sizeof(__be32);
> >> +
> >> + pr_debug("numa_dist_table_len = %d, numa_dist_indexes_len = %d \n",
> >> + numa_dist_table_length, max_numa_index);
> >> +
> >> + for (i = 0; i < max_numa_index; i++)
> >> + /* +1 skip the max_numa_index in the property */
> >> + numa_id_index_table[i] = of_read_number(&numa_lookup_index[i + 1], 1);
> >> +
> >> +
> >> + VM_WARN_ON(numa_dist_table_length != max_numa_index * max_numa_index);
> >
> > Again, you don't actually bail out in this case. And if it has to
> > have this value, what's the point of encoding it into the property.
> >
> >> + for (distance_index = 0; distance_index < numa_dist_table_length; distance_index++) {
> >> + int nodeA = numa_id_index_table[curr_row];
> >> + int nodeB = numa_id_index_table[curr_column++];
> >
> > You've already (sort of) verified that the distance table has size
> > N^2, in which case you can just to a simple two dimensional loop
> > rather than having to do ugly calculations of row and column.
>
> Fixed all the above and updated as below.
> if (numa_dist_table_length != max_numa_index * max_numa_index) {
> WARN(1, "Wrong NUMA distnce information\n");
^^^^^^^
> /* consider everybody else just remote. */
>
> for (i = 0; i < max_numa_index; i++) {
> for (j = 0; j < max_numa_index; j++) {
> int nodeA = numa_id_index_table[i];
> int nodeB = numa_id_index_table[j];
>
> if (nodeA == nodeB)
> numa_distance_table[nodeA][nodeB] = LOCAL_DISTANCE;
> else
> numa_distance_table[nodeA][nodeB] = REMOTE_DISTANCE;
> }
> }
> }
>
> distance_index = 0;
> for (i = 0; i < max_numa_index; i++) {
> for (j = 0; j < max_numa_index; j++) {
> int nodeA = numa_id_index_table[i];
> int nodeB = numa_id_index_table[j];
>
> numa_distance_table[nodeA][nodeB] = numa_dist_table[distance_index++];
>
> pr_debug("dist[%d][%d]=%d ", nodeA, nodeB, numa_distance_table[nodeA][nodeB]);
> }
> }
> }
>
>
> -aneesh
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH 0/8] powerpc: fast interrupt exit bug and misc fixes
From: Nicholas Piggin @ 2021-06-28 7:49 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Sachin Sant, Nicholas Piggin
This is a bunch of fixes for powerpc next, mostly a nasty hole in fast
interrupt exit code found by Sachin and some other bits along the way
while looking at it.
So far this survives about 5 hours of stress testing with a workload
that would trigger it in a few seconds (guest 128 vcpus running kernel
compile loops with perf record -ag running in the background).
Thanks,
Nick
Nicholas Piggin (8):
powerpc/64e: fix CONFIG_RELOCATABLE build
powerpc/64e: remove implicit soft-masking and interrupt exit restart
logic
powerpc/64s: add a table of implicit soft-masked addresses
powerpc/64s/interrupt: preserve regs->softe for NMI interrupts
powerpc/64: enable MSR[EE] in irq replay pt_regs
powerpc/64/interrupts: add missing kprobe annotations on interrupt
exit symbols
powerpc/64s/interrupt: clean up interrupt return labels
powerpc/64s: move ret_from_fork etc above __end_soft_masked
arch/powerpc/include/asm/interrupt.h | 41 ++++++++++---
arch/powerpc/include/asm/ppc_asm.h | 7 +++
arch/powerpc/kernel/exceptions-64e.S | 23 +++----
arch/powerpc/kernel/exceptions-64s.S | 55 ++++++++++++++---
arch/powerpc/kernel/interrupt_64.S | 90 ++++++++++++++++++----------
arch/powerpc/kernel/irq.c | 1 +
arch/powerpc/kernel/vmlinux.lds.S | 9 +++
arch/powerpc/lib/restart_table.c | 26 ++++++++
8 files changed, 194 insertions(+), 58 deletions(-)
--
2.23.0
^ permalink raw reply
* [PATCH 1/8] powerpc/64e: fix CONFIG_RELOCATABLE build
From: Nicholas Piggin @ 2021-06-28 7:49 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Sachin Sant, Nicholas Piggin
In-Reply-To: <20210628074932.1499554-1-npiggin@gmail.com>
Commit 24d33ac5b8ff ("powerpc/64s: Make prom_init require RELOCATABLE")
also made my 64e config require RELOCATABLE, which results in compile
failures.
Whether or not that's the right thing to do for prom_init for 64e, this
fixes CONFIG_RELOCATABLE=y compile errors. That commit is marked as
being fixed, but only because that's what caused the compile error to
show up for a given config.
This passes basic qemu testing.
Fixes: 24d33ac5b8ff ("powerpc/64s: Make prom_init require RELOCATABLE")
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/kernel/exceptions-64e.S | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/powerpc/kernel/exceptions-64e.S b/arch/powerpc/kernel/exceptions-64e.S
index 22fcd95dd8dc..d634bfceed2c 100644
--- a/arch/powerpc/kernel/exceptions-64e.S
+++ b/arch/powerpc/kernel/exceptions-64e.S
@@ -912,8 +912,14 @@ kernel_dbg_exc:
b interrupt_return
.macro SEARCH_RESTART_TABLE
+#ifdef CONFIG_RELOCATABLE
+ ld r11,PACATOC(r13)
+ ld r14,__start___restart_table@got(r11)
+ ld r15,__stop___restart_table@got(r11)
+#else
LOAD_REG_IMMEDIATE_SYM(r14, r11, __start___restart_table)
LOAD_REG_IMMEDIATE_SYM(r15, r11, __stop___restart_table)
+#endif
300:
cmpd r14,r15
beq 302f
@@ -1329,7 +1335,12 @@ a2_tlbinit_code_start:
a2_tlbinit_after_linear_map:
/* Now we branch the new virtual address mapped by this entry */
+#ifdef CONFIG_RELOCATABLE
+ ld r5,PACATOC(r13)
+ ld r3,1f@got(r5)
+#else
LOAD_REG_IMMEDIATE_SYM(r3, r5, 1f)
+#endif
mtctr r3
bctr
--
2.23.0
^ permalink raw reply related
* [PATCH 2/8] powerpc/64e: remove implicit soft-masking and interrupt exit restart logic
From: Nicholas Piggin @ 2021-06-28 7:49 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Sachin Sant, Nicholas Piggin
In-Reply-To: <20210628074932.1499554-1-npiggin@gmail.com>
The implicit soft-masking to speed up interrupt return was going to be
used by 64e as well, but it was not ready in time. 64e always disables
MSR[EE] when exiting from interrupt and syscall.
Disable it for now.
Fixes: 9d1988ca87dd ("powerpc/64: treat low kernel text as irqs soft-masked")
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/include/asm/interrupt.h | 33 ++++++++++++++++++++--------
arch/powerpc/kernel/exceptions-64e.S | 12 +---------
arch/powerpc/kernel/interrupt_64.S | 16 +++++++++++++-
3 files changed, 40 insertions(+), 21 deletions(-)
diff --git a/arch/powerpc/include/asm/interrupt.h b/arch/powerpc/include/asm/interrupt.h
index 8b4b1e84e110..f2481fac7f7f 100644
--- a/arch/powerpc/include/asm/interrupt.h
+++ b/arch/powerpc/include/asm/interrupt.h
@@ -73,20 +73,34 @@
#include <asm/kprobes.h>
#include <asm/runlatch.h>
-#ifdef CONFIG_PPC64
+#ifdef CONFIG_PPC_BOOK3S_64
extern char __end_soft_masked[];
unsigned long search_kernel_restart_table(unsigned long addr);
-#endif
-#ifdef CONFIG_PPC_BOOK3S_64
DECLARE_STATIC_KEY_FALSE(interrupt_exit_not_reentrant);
+bool is_implicit_soft_masked(struct pt_regs *regs)
+{
+ if (regs->msr & MSR_PR)
+ return false;
+
+ if (regs->nip >= (unsigned long)__end_soft_masked)
+ return false;
+
+ return true;
+}
+
static inline void srr_regs_clobbered(void)
{
local_paca->srr_valid = 0;
local_paca->hsrr_valid = 0;
}
#else
+static inline bool is_implicit_soft_masked(struct pt_regs *regs)
+{
+ return false;
+}
+
static inline void srr_regs_clobbered(void)
{
}
@@ -150,11 +164,13 @@ static inline void interrupt_enter_prepare(struct pt_regs *regs, struct interrup
*/
if (TRAP(regs) != INTERRUPT_PROGRAM) {
CT_WARN_ON(ct_state() != CONTEXT_KERNEL);
- BUG_ON(regs->nip < (unsigned long)__end_soft_masked);
+ BUG_ON(is_implicit_soft_masked(regs));
}
+#ifdef CONFIG_PPC_BOOK3S
/* Move this under a debugging check */
if (arch_irq_disabled_regs(regs))
BUG_ON(search_kernel_restart_table(regs->nip));
+#endif
}
#endif
@@ -244,10 +260,9 @@ static inline void interrupt_nmi_enter_prepare(struct pt_regs *regs, struct inte
local_paca->irq_soft_mask = IRQS_ALL_DISABLED;
local_paca->irq_happened |= PACA_IRQ_HARD_DIS;
- if (IS_ENABLED(CONFIG_PPC_BOOK3S_64) && !(regs->msr & MSR_PR) &&
- regs->nip < (unsigned long)__end_soft_masked) {
- // Kernel code running below __end_soft_masked is
- // implicitly soft-masked.
+ if (is_implicit_soft_masked(regs)) {
+ // Adjust regs->softe soft implicit soft-mask, so
+ // arch_irq_disabled_regs(regs) behaves as expected.
regs->softe = IRQS_ALL_DISABLED;
}
@@ -282,6 +297,7 @@ static inline void interrupt_nmi_exit_prepare(struct pt_regs *regs, struct inter
*/
#ifdef CONFIG_PPC64
+#ifdef CONFIG_PPC_BOOK3S
if (arch_irq_disabled_regs(regs)) {
unsigned long rst = search_kernel_restart_table(regs->nip);
if (rst)
@@ -289,7 +305,6 @@ static inline void interrupt_nmi_exit_prepare(struct pt_regs *regs, struct inter
}
#endif
-#ifdef CONFIG_PPC64
if (nmi_disables_ftrace(regs))
this_cpu_set_ftrace_enabled(state->ftrace_enabled);
diff --git a/arch/powerpc/kernel/exceptions-64e.S b/arch/powerpc/kernel/exceptions-64e.S
index d634bfceed2c..1401787b0b93 100644
--- a/arch/powerpc/kernel/exceptions-64e.S
+++ b/arch/powerpc/kernel/exceptions-64e.S
@@ -342,17 +342,7 @@ ret_from_mc_except:
#define PROLOG_ADDITION_MASKABLE_GEN(n) \
lbz r10,PACAIRQSOFTMASK(r13); /* are irqs soft-masked? */ \
andi. r10,r10,IRQS_DISABLED; /* yes -> go out of line */ \
- bne masked_interrupt_book3e_##n; \
- /* Kernel code below __end_soft_masked is implicitly masked */ \
- andi. r10,r11,MSR_PR; \
- bne 1f; /* user -> not masked */ \
- std r14,PACA_EXGEN+EX_R14(r13); \
- LOAD_REG_IMMEDIATE_SYM(r14, r10, __end_soft_masked); \
- mfspr r10,SPRN_SRR0; \
- cmpld r10,r14; \
- ld r14,PACA_EXGEN+EX_R14(r13); \
- blt masked_interrupt_book3e_##n; \
-1:
+ bne masked_interrupt_book3e_##n
/*
* Additional regs must be re-loaded from paca before EXCEPTION_COMMON* is
diff --git a/arch/powerpc/kernel/interrupt_64.S b/arch/powerpc/kernel/interrupt_64.S
index e7a50613a570..0a8afec6c07b 100644
--- a/arch/powerpc/kernel/interrupt_64.S
+++ b/arch/powerpc/kernel/interrupt_64.S
@@ -196,6 +196,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
RFI_TO_USER
.Lsyscall_vectored_\name\()_rst_end:
+#ifdef CONFIG_PPC_BOOK3S
syscall_vectored_\name\()_restart:
GET_PACA(r13)
ld r1,PACA_EXIT_SAVE_R1(r13)
@@ -209,6 +210,7 @@ syscall_vectored_\name\()_restart:
b .Lsyscall_vectored_\name\()_rst_start
RESTART_TABLE(.Lsyscall_vectored_\name\()_rst_start, .Lsyscall_vectored_\name\()_rst_end, syscall_vectored_\name\()_restart)
+#endif
.endm
@@ -320,10 +322,12 @@ END_BTB_FLUSH_SECTION
li r5,0 /* !scv */
bl syscall_exit_prepare
std r1,PACA_EXIT_SAVE_R1(r13) /* save r1 for restart */
+#ifdef CONFIG_PPC_BOOK3S
.Lsyscall_rst_start:
lbz r11,PACAIRQHAPPENED(r13)
andi. r11,r11,(~PACA_IRQ_HARD_DIS)@l
bne- syscall_restart
+#endif
li r11,IRQS_ENABLED
stb r11,PACAIRQSOFTMASK(r13)
li r11,0
@@ -396,6 +400,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
b .Lsyscall_restore_regs_cont
.Lsyscall_rst_end:
+#ifdef CONFIG_PPC_BOOK3S
syscall_restart:
GET_PACA(r13)
ld r1,PACA_EXIT_SAVE_R1(r13)
@@ -409,6 +414,7 @@ syscall_restart:
b .Lsyscall_rst_start
RESTART_TABLE(.Lsyscall_rst_start, .Lsyscall_rst_end, syscall_restart)
+#endif
#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
tabort_syscall:
@@ -504,10 +510,12 @@ _ASM_NOKPROBE_SYMBOL(interrupt_return_\srr\())
bne- .Lrestore_nvgprs_\srr
.Lrestore_nvgprs_\srr\()_cont:
std r1,PACA_EXIT_SAVE_R1(r13) /* save r1 for restart */
+#ifdef CONFIG_PPC_BOOK3S
.Linterrupt_return_\srr\()_user_rst_start:
lbz r11,PACAIRQHAPPENED(r13)
andi. r11,r11,(~PACA_IRQ_HARD_DIS)@l
bne- interrupt_return_\srr\()_user_restart
+#endif
li r11,IRQS_ENABLED
stb r11,PACAIRQSOFTMASK(r13)
li r11,0
@@ -590,6 +598,7 @@ ALT_FTR_SECTION_END_IFCLR(CPU_FTR_STCX_CHECKS_ADDRESS)
REST_NVGPRS(r1)
b .Lrestore_nvgprs_\srr\()_cont
+#ifdef CONFIG_PPC_BOOK3S
interrupt_return_\srr\()_user_restart:
GET_PACA(r13)
ld r1,PACA_EXIT_SAVE_R1(r13)
@@ -602,6 +611,7 @@ interrupt_return_\srr\()_user_restart:
b .Linterrupt_return_\srr\()_user_rst_start
RESTART_TABLE(.Linterrupt_return_\srr\()_user_rst_start, .Linterrupt_return_\srr\()_user_rst_end, interrupt_return_\srr\()_user_restart)
+#endif
.balign IFETCH_ALIGN_BYTES
.Lkernel_interrupt_return_\srr\():
@@ -615,9 +625,11 @@ RESTART_TABLE(.Linterrupt_return_\srr\()_user_rst_start, .Linterrupt_return_\srr
cmpwi r11,IRQS_ENABLED
stb r11,PACAIRQSOFTMASK(r13)
bne 1f
+#ifdef CONFIG_PPC_BOOK3S
lbz r11,PACAIRQHAPPENED(r13)
andi. r11,r11,(~PACA_IRQ_HARD_DIS)@l
bne- interrupt_return_\srr\()_kernel_restart
+#endif
li r11,0
stb r11,PACAIRQHAPPENED(r13) # clear out possible HARD_DIS
1:
@@ -717,6 +729,7 @@ ALT_FTR_SECTION_END_IFCLR(CPU_FTR_STCX_CHECKS_ADDRESS)
b . /* prevent speculative execution */
.Linterrupt_return_\srr\()_kernel_rst_end:
+#ifdef CONFIG_PPC_BOOK3S
interrupt_return_\srr\()_kernel_restart:
GET_PACA(r13)
ld r1,PACA_EXIT_SAVE_R1(r13)
@@ -729,14 +742,15 @@ interrupt_return_\srr\()_kernel_restart:
b .Linterrupt_return_\srr\()_kernel_rst_start
RESTART_TABLE(.Linterrupt_return_\srr\()_kernel_rst_start, .Linterrupt_return_\srr\()_kernel_rst_end, interrupt_return_\srr\()_kernel_restart)
+#endif
.endm
interrupt_return_macro srr
#ifdef CONFIG_PPC_BOOK3S
interrupt_return_macro hsrr
-#endif /* CONFIG_PPC_BOOK3S */
.globl __end_soft_masked
__end_soft_masked:
DEFINE_FIXED_SYMBOL(__end_soft_masked)
+#endif /* CONFIG_PPC_BOOK3S */
--
2.23.0
^ permalink raw reply related
* [PATCH 3/8] powerpc/64s: add a table of implicit soft-masked addresses
From: Nicholas Piggin @ 2021-06-28 7:49 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Sachin Sant, Nicholas Piggin
In-Reply-To: <20210628074932.1499554-1-npiggin@gmail.com>
Commit 9d1988ca87dd ("powerpc/64: treat low kernel text as irqs
soft-masked") ends up catching too much code, including ret_from_fork,
and parts of interrupt and syscall return that do not expect to be
interrupts to be soft-masked. If an interrupt gets marked pending,
and then the code proceeds out of the implicit soft-masked region it
will fail to deal with the pending interrupt.
Fix this by adding a new table of addresses which explicitly marks
the regions of code that are soft masked. This table is only checked
for interrupts that below __end_soft_masked, so most kernel interrupts
will not have the overhead of the table search.
Fixes: 9d1988ca87dd ("powerpc/64: treat low kernel text as irqs soft-masked")
Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/include/asm/interrupt.h | 5 ++-
arch/powerpc/include/asm/ppc_asm.h | 7 ++++
arch/powerpc/kernel/exceptions-64s.S | 55 ++++++++++++++++++++++++----
arch/powerpc/kernel/interrupt_64.S | 8 ++++
arch/powerpc/kernel/vmlinux.lds.S | 9 +++++
arch/powerpc/lib/restart_table.c | 26 +++++++++++++
6 files changed, 100 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/include/asm/interrupt.h b/arch/powerpc/include/asm/interrupt.h
index f2481fac7f7f..d7df247a149c 100644
--- a/arch/powerpc/include/asm/interrupt.h
+++ b/arch/powerpc/include/asm/interrupt.h
@@ -75,11 +75,12 @@
#ifdef CONFIG_PPC_BOOK3S_64
extern char __end_soft_masked[];
+bool search_kernel_soft_mask_table(unsigned long addr);
unsigned long search_kernel_restart_table(unsigned long addr);
DECLARE_STATIC_KEY_FALSE(interrupt_exit_not_reentrant);
-bool is_implicit_soft_masked(struct pt_regs *regs)
+static inline bool is_implicit_soft_masked(struct pt_regs *regs)
{
if (regs->msr & MSR_PR)
return false;
@@ -87,7 +88,7 @@ bool is_implicit_soft_masked(struct pt_regs *regs)
if (regs->nip >= (unsigned long)__end_soft_masked)
return false;
- return true;
+ return search_kernel_soft_mask_table(regs->nip);
}
static inline void srr_regs_clobbered(void)
diff --git a/arch/powerpc/include/asm/ppc_asm.h b/arch/powerpc/include/asm/ppc_asm.h
index c9c2c36c1f8f..116c1519728a 100644
--- a/arch/powerpc/include/asm/ppc_asm.h
+++ b/arch/powerpc/include/asm/ppc_asm.h
@@ -762,6 +762,13 @@ END_FTR_SECTION_NESTED(CPU_FTR_CELL_TB_BUG, CPU_FTR_CELL_TB_BUG, 96)
stringify_in_c(.long (_target) - . ;) \
stringify_in_c(.previous)
+#define SOFT_MASK_TABLE(_start, _end) \
+ stringify_in_c(.section __soft_mask_table,"a";)\
+ stringify_in_c(.balign 8;) \
+ stringify_in_c(.llong (_start);) \
+ stringify_in_c(.llong (_end);) \
+ stringify_in_c(.previous)
+
#define RESTART_TABLE(_start, _end, _target) \
stringify_in_c(.section __restart_table,"a";)\
stringify_in_c(.balign 8;) \
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index ecd07bf604c5..3a58c3fd6de4 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -428,21 +428,30 @@ DEFINE_FIXED_SYMBOL(\name\()_common_real)
/* If coming from user, skip soft-mask tests. */
andi. r10,r12,MSR_PR
- bne 2f
+ bne 3f
/*
- * Kernel code running below __end_soft_masked is implicitly
- * soft-masked
+ * Kernel code running below __end_soft_masked may be
+ * implicitly soft-masked if it is within the regions
+ * in the soft mask table.
*/
LOAD_HANDLER(r10, __end_soft_masked)
cmpld r11,r10
-
+ bge+ 1f
+
+ /* SEARCH_SOFT_MASK_TABLE clobbers r9,r10,r12 */
+ stw r9,PACA_EXGEN+EX_CCR(r13)
+ SEARCH_SOFT_MASK_TABLE
+ lwz r9,PACA_EXGEN+EX_CCR(r13)
+ cmpdi r12,0
+ mfspr r12,SPRN_SRR1 /* Restore r12 to SRR1 */
+ beq 1f /* Not in soft-mask table */
li r10,IMASK
- blt- 1f
+ b 2f /* In soft-mask table, always mask */
/* Test the soft mask state against our interrupt's bit */
- lbz r10,PACAIRQSOFTMASK(r13)
-1: andi. r10,r10,IMASK
+1: lbz r10,PACAIRQSOFTMASK(r13)
+2: andi. r10,r10,IMASK
/* Associate vector numbers with bits in paca->irq_happened */
.if IVEC == 0x500 || IVEC == 0xea0
li r10,PACA_IRQ_EE
@@ -473,7 +482,7 @@ DEFINE_FIXED_SYMBOL(\name\()_common_real)
.if ISTACK
andi. r10,r12,MSR_PR /* See if coming from user */
-2: mr r10,r1 /* Save r1 */
+3: mr r10,r1 /* Save r1 */
subi r1,r1,INT_FRAME_SIZE /* alloc frame on kernel stack */
beq- 100f
ld r1,PACAKSAVE(r13) /* kernel stack to use */
@@ -624,6 +633,36 @@ END_FTR_SECTION_IFSET(CPU_FTR_CFAR)
303:
.endm
+.macro SEARCH_SOFT_MASK_TABLE
+#ifdef CONFIG_RELOCATABLE
+ mr r12,r2
+ ld r2,PACATOC(r13)
+ LOAD_REG_ADDR(r9, __start___soft_mask_table)
+ LOAD_REG_ADDR(r10, __stop___soft_mask_table)
+ mr r2,r12
+#else
+ LOAD_REG_IMMEDIATE_SYM(r9, r12, __start___soft_mask_table)
+ LOAD_REG_IMMEDIATE_SYM(r10, r12, __stop___soft_mask_table)
+#endif
+300:
+ cmpd r9,r10
+ beq 302f
+ ld r12,0(r9)
+ cmpld r11,r12
+ blt 301f
+ ld r12,8(r9)
+ cmpld r11,r12
+ bge 301f
+ li r12,1
+ b 303f
+301:
+ addi r9,r9,16
+ b 300b
+302:
+ li r12,0
+303:
+.endm
+
/*
* Restore all registers including H/SRR0/1 saved in a stack frame of a
* standard exception.
diff --git a/arch/powerpc/kernel/interrupt_64.S b/arch/powerpc/kernel/interrupt_64.S
index 0a8afec6c07b..c06ed64541e1 100644
--- a/arch/powerpc/kernel/interrupt_64.S
+++ b/arch/powerpc/kernel/interrupt_64.S
@@ -208,7 +208,9 @@ syscall_vectored_\name\()_restart:
bl syscall_exit_restart
std r1,PACA_EXIT_SAVE_R1(r13) /* save r1 for restart */
b .Lsyscall_vectored_\name\()_rst_start
+1:
+SOFT_MASK_TABLE(.Lsyscall_vectored_\name\()_rst_start, 1b)
RESTART_TABLE(.Lsyscall_vectored_\name\()_rst_start, .Lsyscall_vectored_\name\()_rst_end, syscall_vectored_\name\()_restart)
#endif
@@ -412,7 +414,9 @@ syscall_restart:
bl syscall_exit_restart
std r1,PACA_EXIT_SAVE_R1(r13) /* save r1 for restart */
b .Lsyscall_rst_start
+1:
+SOFT_MASK_TABLE(.Lsyscall_rst_start, 1b)
RESTART_TABLE(.Lsyscall_rst_start, .Lsyscall_rst_end, syscall_restart)
#endif
@@ -609,7 +613,9 @@ interrupt_return_\srr\()_user_restart:
bl interrupt_exit_user_restart
std r1,PACA_EXIT_SAVE_R1(r13) /* save r1 for restart */
b .Linterrupt_return_\srr\()_user_rst_start
+1:
+SOFT_MASK_TABLE(.Linterrupt_return_\srr\()_user_rst_start, 1b)
RESTART_TABLE(.Linterrupt_return_\srr\()_user_rst_start, .Linterrupt_return_\srr\()_user_rst_end, interrupt_return_\srr\()_user_restart)
#endif
@@ -740,7 +746,9 @@ interrupt_return_\srr\()_kernel_restart:
bl interrupt_exit_kernel_restart
std r1,PACA_EXIT_SAVE_R1(r13) /* save r1 for restart */
b .Linterrupt_return_\srr\()_kernel_rst_start
+1:
+SOFT_MASK_TABLE(.Linterrupt_return_\srr\()_kernel_rst_start, 1b)
RESTART_TABLE(.Linterrupt_return_\srr\()_kernel_rst_start, .Linterrupt_return_\srr\()_kernel_rst_end, interrupt_return_\srr\()_kernel_restart)
#endif
diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S
index 16c5e13e00c4..40bdefe9caa7 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -9,6 +9,14 @@
#define EMITS_PT_NOTE
#define RO_EXCEPTION_TABLE_ALIGN 0
+#define SOFT_MASK_TABLE(align) \
+ . = ALIGN(align); \
+ __soft_mask_table : AT(ADDR(__soft_mask_table) - LOAD_OFFSET) { \
+ __start___soft_mask_table = .; \
+ KEEP(*(__soft_mask_table)) \
+ __stop___soft_mask_table = .; \
+ }
+
#define RESTART_TABLE(align) \
. = ALIGN(align); \
__restart_table : AT(ADDR(__restart_table) - LOAD_OFFSET) { \
@@ -132,6 +140,7 @@ SECTIONS
RO_DATA(PAGE_SIZE)
#ifdef CONFIG_PPC64
+ SOFT_MASK_TABLE(8)
RESTART_TABLE(8)
. = ALIGN(8);
diff --git a/arch/powerpc/lib/restart_table.c b/arch/powerpc/lib/restart_table.c
index 7cd20757cc33..bccb662c1b7b 100644
--- a/arch/powerpc/lib/restart_table.c
+++ b/arch/powerpc/lib/restart_table.c
@@ -1,15 +1,41 @@
#include <asm/interrupt.h>
#include <asm/kprobes.h>
+struct soft_mask_table_entry {
+ unsigned long start;
+ unsigned long end;
+};
+
struct restart_table_entry {
unsigned long start;
unsigned long end;
unsigned long fixup;
};
+extern struct soft_mask_table_entry __start___soft_mask_table[];
+extern struct soft_mask_table_entry __stop___soft_mask_table[];
+
extern struct restart_table_entry __start___restart_table[];
extern struct restart_table_entry __stop___restart_table[];
+/* Given an address, look for it in the soft mask table */
+bool search_kernel_soft_mask_table(unsigned long addr)
+{
+ struct soft_mask_table_entry *smte = __start___soft_mask_table;
+
+ while (smte < __stop___soft_mask_table) {
+ unsigned long start = smte->start;
+ unsigned long end = smte->end;
+
+ if (addr >= start && addr < end)
+ return true;
+
+ smte++;
+ }
+ return false;
+}
+NOKPROBE_SYMBOL(search_kernel_soft_mask_table);
+
/* Given an address, look for it in the kernel exception table */
unsigned long search_kernel_restart_table(unsigned long addr)
{
--
2.23.0
^ permalink raw reply related
* [PATCH 4/8] powerpc/64s/interrupt: preserve regs->softe for NMI interrupts
From: Nicholas Piggin @ 2021-06-28 7:49 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Sachin Sant, Nicholas Piggin
In-Reply-To: <20210628074932.1499554-1-npiggin@gmail.com>
If an NMI interrupt hits in an implicit soft-masked region, regs->softe
is modified to reflect that. This may not be necessary for correctness
at the moment, but it is less surprising and it's unhelpful when
debugging or adding checks.
Make sure this is changed back to how it was found before returning.
Fixes: 4ec5feec1ad0 ("powerpc/64s: Make NMI record implicitly soft-masked code as irqs disabled")
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/include/asm/interrupt.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/include/asm/interrupt.h b/arch/powerpc/include/asm/interrupt.h
index d7df247a149c..789311d1e283 100644
--- a/arch/powerpc/include/asm/interrupt.h
+++ b/arch/powerpc/include/asm/interrupt.h
@@ -227,6 +227,7 @@ struct interrupt_nmi_state {
u8 irq_soft_mask;
u8 irq_happened;
u8 ftrace_enabled;
+ u64 softe;
#endif
};
@@ -252,6 +253,7 @@ static inline void interrupt_nmi_enter_prepare(struct pt_regs *regs, struct inte
#ifdef CONFIG_PPC64
state->irq_soft_mask = local_paca->irq_soft_mask;
state->irq_happened = local_paca->irq_happened;
+ state->softe = regs->softe;
/*
* Set IRQS_ALL_DISABLED unconditionally so irqs_disabled() does
@@ -311,6 +313,7 @@ static inline void interrupt_nmi_exit_prepare(struct pt_regs *regs, struct inter
/* Check we didn't change the pending interrupt mask. */
WARN_ON_ONCE((state->irq_happened | PACA_IRQ_HARD_DIS) != local_paca->irq_happened);
+ regs->softe = state->softe;
local_paca->irq_happened = state->irq_happened;
local_paca->irq_soft_mask = state->irq_soft_mask;
#endif
--
2.23.0
^ permalink raw reply related
* [PATCH 5/8] powerpc/64: enable MSR[EE] in irq replay pt_regs
From: Nicholas Piggin @ 2021-06-28 7:49 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Sachin Sant, Nicholas Piggin
In-Reply-To: <20210628074932.1499554-1-npiggin@gmail.com>
Similar to 2b48e96be2f9f ("powerpc/64: fix irq replay pt_regs->softe
value"), enable MSR_EE in pt_regs->msr, which makes the regs look a
bit more normal and allows the extra debug checks to be added to
interrupt handler entry.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/include/asm/interrupt.h | 4 ++++
arch/powerpc/kernel/irq.c | 1 +
2 files changed, 5 insertions(+)
diff --git a/arch/powerpc/include/asm/interrupt.h b/arch/powerpc/include/asm/interrupt.h
index 789311d1e283..d4bdf7d274ac 100644
--- a/arch/powerpc/include/asm/interrupt.h
+++ b/arch/powerpc/include/asm/interrupt.h
@@ -173,6 +173,8 @@ static inline void interrupt_enter_prepare(struct pt_regs *regs, struct interrup
BUG_ON(search_kernel_restart_table(regs->nip));
#endif
}
+ if (IS_ENABLED(CONFIG_PPC_IRQ_SOFT_MASK_DEBUG))
+ BUG_ON(!arch_irq_disabled_regs(regs) && !(regs->msr & MSR_EE));
#endif
booke_restore_dbcr0();
@@ -268,6 +270,8 @@ static inline void interrupt_nmi_enter_prepare(struct pt_regs *regs, struct inte
// arch_irq_disabled_regs(regs) behaves as expected.
regs->softe = IRQS_ALL_DISABLED;
}
+ if (IS_ENABLED(CONFIG_PPC_IRQ_SOFT_MASK_DEBUG))
+ BUG_ON(!arch_irq_disabled_regs(regs) && !(regs->msr & MSR_EE));
/* Don't do any per-CPU operations until interrupt state is fixed */
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 8428caf3194e..91e63eac4e8f 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -121,6 +121,7 @@ void replay_soft_interrupts(void)
ppc_save_regs(®s);
regs.softe = IRQS_ENABLED;
+ regs.msr |= MSR_EE;
again:
if (IS_ENABLED(CONFIG_PPC_IRQ_SOFT_MASK_DEBUG))
--
2.23.0
^ permalink raw reply related
* [PATCH 6/8] powerpc/64/interrupts: add missing kprobe annotations on interrupt exit symbols
From: Nicholas Piggin @ 2021-06-28 7:49 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Sachin Sant, Nicholas Piggin
In-Reply-To: <20210628074932.1499554-1-npiggin@gmail.com>
If one interrupt exit symbol must not be kprobed, none of them can be,
really.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/kernel/interrupt_64.S | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/powerpc/kernel/interrupt_64.S b/arch/powerpc/kernel/interrupt_64.S
index c06ed64541e1..06244b4df719 100644
--- a/arch/powerpc/kernel/interrupt_64.S
+++ b/arch/powerpc/kernel/interrupt_64.S
@@ -198,6 +198,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
#ifdef CONFIG_PPC_BOOK3S
syscall_vectored_\name\()_restart:
+_ASM_NOKPROBE_SYMBOL(syscall_vectored_\name\()_restart)
GET_PACA(r13)
ld r1,PACA_EXIT_SAVE_R1(r13)
ld r2,PACATOC(r13)
@@ -240,6 +241,7 @@ _ASM_NOKPROBE_SYMBOL(system_call_vectored_emulate)
.balign IFETCH_ALIGN_BYTES
.globl system_call_common_real
system_call_common_real:
+_ASM_NOKPROBE_SYMBOL(system_call_common_real)
ld r10,PACAKMSR(r13) /* get MSR value for kernel */
mtmsrd r10
@@ -404,6 +406,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
#ifdef CONFIG_PPC_BOOK3S
syscall_restart:
+_ASM_NOKPROBE_SYMBOL(syscall_restart)
GET_PACA(r13)
ld r1,PACA_EXIT_SAVE_R1(r13)
ld r2,PACATOC(r13)
@@ -422,6 +425,7 @@ RESTART_TABLE(.Lsyscall_rst_start, .Lsyscall_rst_end, syscall_restart)
#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
tabort_syscall:
+_ASM_NOKPROBE_SYMBOL(tabort_syscall)
/* Firstly we need to enable TM in the kernel */
mfmsr r10
li r9, 1
@@ -604,6 +608,7 @@ ALT_FTR_SECTION_END_IFCLR(CPU_FTR_STCX_CHECKS_ADDRESS)
#ifdef CONFIG_PPC_BOOK3S
interrupt_return_\srr\()_user_restart:
+_ASM_NOKPROBE_SYMBOL(interrupt_return_\srr\()_user_restart)
GET_PACA(r13)
ld r1,PACA_EXIT_SAVE_R1(r13)
ld r2,PACATOC(r13)
@@ -737,6 +742,7 @@ ALT_FTR_SECTION_END_IFCLR(CPU_FTR_STCX_CHECKS_ADDRESS)
#ifdef CONFIG_PPC_BOOK3S
interrupt_return_\srr\()_kernel_restart:
+_ASM_NOKPROBE_SYMBOL(interrupt_return_\srr\()_kernel_restart)
GET_PACA(r13)
ld r1,PACA_EXIT_SAVE_R1(r13)
ld r2,PACATOC(r13)
--
2.23.0
^ permalink raw reply related
* [PATCH 7/8] powerpc/64s/interrupt: clean up interrupt return labels
From: Nicholas Piggin @ 2021-06-28 7:49 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Sachin Sant, Nicholas Piggin
In-Reply-To: <20210628074932.1499554-1-npiggin@gmail.com>
Normal kernel-interrupt exits can get interrupt_return_srr_user_restart
in their backtrace, which is an unusual and notable function, and it is
part of the user-interrupt exit path, which is doubly confusing.
Add symmetric non-local labels for user and kernel interrupt exit cases
to address this. Also get rid of an unused label.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/kernel/interrupt_64.S | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/interrupt_64.S b/arch/powerpc/kernel/interrupt_64.S
index 06244b4df719..795c105850e4 100644
--- a/arch/powerpc/kernel/interrupt_64.S
+++ b/arch/powerpc/kernel/interrupt_64.S
@@ -511,7 +511,9 @@ interrupt_return_\srr\():
_ASM_NOKPROBE_SYMBOL(interrupt_return_\srr\())
ld r4,_MSR(r1)
andi. r0,r4,MSR_PR
- beq .Lkernel_interrupt_return_\srr
+ beq interrupt_return_\srr\()_kernel
+interrupt_return_\srr\()_user: /* make backtraces match the _kernel variant */
+_ASM_NOKPROBE_SYMBOL(interrupt_return_\srr\()_user)
addi r3,r1,STACK_FRAME_OVERHEAD
bl interrupt_exit_user_prepare
cmpdi r3,0
@@ -625,8 +627,8 @@ RESTART_TABLE(.Linterrupt_return_\srr\()_user_rst_start, .Linterrupt_return_\srr
#endif
.balign IFETCH_ALIGN_BYTES
-.Lkernel_interrupt_return_\srr\():
-.Linterrupt_return_\srr\()_kernel:
+interrupt_return_\srr\()_kernel:
+_ASM_NOKPROBE_SYMBOL(interrupt_return_\srr\()_kernel)
addi r3,r1,STACK_FRAME_OVERHEAD
bl interrupt_exit_kernel_prepare
--
2.23.0
^ permalink raw reply related
* [PATCH 8/8] powerpc/64s: move ret_from_fork etc above __end_soft_masked
From: Nicholas Piggin @ 2021-06-28 7:49 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Sachin Sant, Nicholas Piggin
In-Reply-To: <20210628074932.1499554-1-npiggin@gmail.com>
Code which runs with interrupts enabled should be moved above
__end_soft_masked where possible, because maskable interrupts that hit
below there need to consult the soft mask table.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/kernel/interrupt_64.S | 52 +++++++++++++++---------------
1 file changed, 26 insertions(+), 26 deletions(-)
diff --git a/arch/powerpc/kernel/interrupt_64.S b/arch/powerpc/kernel/interrupt_64.S
index 795c105850e4..3ca3576690ce 100644
--- a/arch/powerpc/kernel/interrupt_64.S
+++ b/arch/powerpc/kernel/interrupt_64.S
@@ -451,32 +451,6 @@ _ASM_NOKPROBE_SYMBOL(tabort_syscall)
b . /* prevent speculative execution */
#endif
-#ifdef CONFIG_PPC_BOOK3S
-_GLOBAL(ret_from_fork_scv)
- bl schedule_tail
- REST_NVGPRS(r1)
- li r3,0 /* fork() return value */
- b .Lsyscall_vectored_common_exit
-#endif
-
-_GLOBAL(ret_from_fork)
- bl schedule_tail
- REST_NVGPRS(r1)
- li r3,0 /* fork() return value */
- b .Lsyscall_exit
-
-_GLOBAL(ret_from_kernel_thread)
- bl schedule_tail
- REST_NVGPRS(r1)
- mtctr r14
- mr r3,r15
-#ifdef PPC64_ELF_ABI_v2
- mr r12,r14
-#endif
- bctrl
- li r3,0
- b .Lsyscall_exit
-
/*
* If MSR EE/RI was never enabled, IRQs not reconciled, NVGPRs not
* touched, no exit work created, then this can be used.
@@ -770,3 +744,29 @@ interrupt_return_macro hsrr
__end_soft_masked:
DEFINE_FIXED_SYMBOL(__end_soft_masked)
#endif /* CONFIG_PPC_BOOK3S */
+
+#ifdef CONFIG_PPC_BOOK3S
+_GLOBAL(ret_from_fork_scv)
+ bl schedule_tail
+ REST_NVGPRS(r1)
+ li r3,0 /* fork() return value */
+ b .Lsyscall_vectored_common_exit
+#endif
+
+_GLOBAL(ret_from_fork)
+ bl schedule_tail
+ REST_NVGPRS(r1)
+ li r3,0 /* fork() return value */
+ b .Lsyscall_exit
+
+_GLOBAL(ret_from_kernel_thread)
+ bl schedule_tail
+ REST_NVGPRS(r1)
+ mtctr r14
+ mr r3,r15
+#ifdef PPC64_ELF_ABI_v2
+ mr r12,r14
+#endif
+ bctrl
+ li r3,0
+ b .Lsyscall_exit
--
2.23.0
^ permalink raw reply related
* linux-next: manual merge of the akpm tree with the powerpc tree
From: Stephen Rothwell @ 2021-06-28 9:56 UTC (permalink / raw)
To: Andrew Morton, Michael Ellerman, PowerPC
Cc: Kefeng Wang, Linux Next Mailing List, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 774 bytes --]
Hi all,
Today's linux-next merge of the akpm tree got a conflict in:
arch/powerpc/kernel/setup-common.c
between commit:
56afad885228 ("powerpc: Remove klimit")
from the powerpc tree and commit:
6e6e0df2a484 ("powerpc: convert to setup_initial_init_mm()")
from the akpm tree.
I fixed it up (I just used the latter since it had also decided to use
_end directly) and can carry the fix as necessary. This is now fixed as
far as linux-next is concerned, but any non trivial conflicts should be
mentioned to your upstream maintainer when your tree is submitted for
merging. You may also want to consider cooperating with the maintainer
of the conflicting tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [RFC] fpga: dfl: fme: Fix cpu hotplug code
From: kajoljain @ 2021-06-28 10:04 UTC (permalink / raw)
To: Xu Yilun
Cc: mark.rutland, maddy, luwei.kang, rnsastry, trix, linux-fpga,
linuxppc-dev, linux-kernel, atrajeev, mdf, will, hao.wu
In-Reply-To: <20210628090146.GA80012@yilunxu-OptiPlex-7050>
On 6/28/21 2:31 PM, Xu Yilun wrote:
> It's a good fix, you can drop the RFC in commit title. :)
>
> The title could be more specific, like:
>
> fpga: dfl: fme: Fix cpu hotplug issue in performance reporting
>
> So we know it is for performance reporting feature at first glance.
>
> On Mon, Jun 28, 2021 at 12:45:46PM +0530, Kajol Jain wrote:
>
>> Commit 724142f8c42a ("fpga: dfl: fme: add performance
>> reporting support") added performance reporting support
>> for FPGA management engine via perf.
>
> May drop this section, it is indicated in the Fixes tag.
>
Hi Yilun,
Thanks for testing the patch. I will make mentioned changes and send
new patch.
Thanks,
Kajol Jain
>>
>> It also added cpu hotplug feature but it didn't add
>
> The performance reporting driver added cpu hotplug ...
>
>> pmu migration call in cpu offline function.
>> This can create an issue incase the current designated
>> cpu being used to collect fme pmu data got offline,
>> as based on current code we are not migrating fme pmu to
>> new target cpu. Because of that perf will still try to
>> fetch data from that offline cpu and hence we will not
>> get counter data.
>>
>> Patch fixed this issue by adding pmu_migrate_context call
>> in fme_perf_offline_cpu function.
>>
>> Fixes: 724142f8c42a ("fpga: dfl: fme: add performance reporting support")
>> Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
>
> Tested-by: Xu Yilun <yilun.xu@intel.com>
>
> Thanks,
> Yilun
>
>> ---
>> drivers/fpga/dfl-fme-perf.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> ---
>> - This fix patch is not tested (as I don't have required environment).
>> But issue mentioned in the commit msg can be re-created, by starting any
>> fme_perf event and while its still running, offline current designated
>> cpu pointed by cpumask file. Since current code didn't migrating pmu,
>> perf gonna try getting counts from that offlined cpu and hence we will
>> not get event data.
>> ---
>> diff --git a/drivers/fpga/dfl-fme-perf.c b/drivers/fpga/dfl-fme-perf.c
>> index 4299145ef347..b9a54583e505 100644
>> --- a/drivers/fpga/dfl-fme-perf.c
>> +++ b/drivers/fpga/dfl-fme-perf.c
>> @@ -953,6 +953,10 @@ static int fme_perf_offline_cpu(unsigned int cpu, struct hlist_node *node)
>> return 0;
>>
>> priv->cpu = target;
>> +
>> + /* Migrate fme_perf pmu events to the new target cpu */
>> + perf_pmu_migrate_context(&priv->pmu, cpu, target);
>> +
>> return 0;
>> }
>>
>> --
>> 2.31.1
^ permalink raw reply
* [PATCH] fpga: dfl: fme: Fix cpu hotplug issue in performance reporting
From: Kajol Jain @ 2021-06-28 10:17 UTC (permalink / raw)
To: will, hao.wu, mark.rutland
Cc: maddy, rnsastry, trix, linux-fpga, linux-kernel, linux-perf-users,
atrajeev, mdf, kjain, linuxppc-dev, yilun.xu
The performance reporting driver added cpu hotplug
feature but it didn't add pmu migration call in cpu
offline function.
This can create an issue incase the current designated
cpu being used to collect fme pmu data got offline,
as based on current code we are not migrating fme pmu to
new target cpu. Because of that perf will still try to
fetch data from that offline cpu and hence we will not
get counter data.
Patch fixed this issue by adding pmu_migrate_context call
in fme_perf_offline_cpu function.
Fixes: 724142f8c42a ("fpga: dfl: fme: add performance reporting support")
Tested-by: Xu Yilun <yilun.xu@intel.com>
Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
---
drivers/fpga/dfl-fme-perf.c | 4 ++++
1 file changed, 4 insertions(+)
---
Changelog:
- Remove RFC tag
- Did nits changes on subject and commit message as suggested by Xu Yilun
- Added Tested-by tag
- Link to rfc patch: https://lkml.org/lkml/2021/6/28/112
---
diff --git a/drivers/fpga/dfl-fme-perf.c b/drivers/fpga/dfl-fme-perf.c
index 4299145ef347..b9a54583e505 100644
--- a/drivers/fpga/dfl-fme-perf.c
+++ b/drivers/fpga/dfl-fme-perf.c
@@ -953,6 +953,10 @@ static int fme_perf_offline_cpu(unsigned int cpu, struct hlist_node *node)
return 0;
priv->cpu = target;
+
+ /* Migrate fme_perf pmu events to the new target cpu */
+ perf_pmu_migrate_context(&priv->pmu, cpu, target);
+
return 0;
}
--
2.31.1
^ permalink raw reply related
* Re: [RFC] fpga: dfl: fme: Fix cpu hotplug code
From: Xu Yilun @ 2021-06-28 9:01 UTC (permalink / raw)
To: Kajol Jain
Cc: mark.rutland, maddy, luwei.kang, rnsastry, trix, linux-fpga,
linuxppc-dev, linux-kernel, atrajeev, mdf, will, hao.wu
In-Reply-To: <20210628071546.167088-1-kjain@linux.ibm.com>
It's a good fix, you can drop the RFC in commit title. :)
The title could be more specific, like:
fpga: dfl: fme: Fix cpu hotplug issue in performance reporting
So we know it is for performance reporting feature at first glance.
On Mon, Jun 28, 2021 at 12:45:46PM +0530, Kajol Jain wrote:
> Commit 724142f8c42a ("fpga: dfl: fme: add performance
> reporting support") added performance reporting support
> for FPGA management engine via perf.
May drop this section, it is indicated in the Fixes tag.
>
> It also added cpu hotplug feature but it didn't add
The performance reporting driver added cpu hotplug ...
> pmu migration call in cpu offline function.
> This can create an issue incase the current designated
> cpu being used to collect fme pmu data got offline,
> as based on current code we are not migrating fme pmu to
> new target cpu. Because of that perf will still try to
> fetch data from that offline cpu and hence we will not
> get counter data.
>
> Patch fixed this issue by adding pmu_migrate_context call
> in fme_perf_offline_cpu function.
>
> Fixes: 724142f8c42a ("fpga: dfl: fme: add performance reporting support")
> Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
Tested-by: Xu Yilun <yilun.xu@intel.com>
Thanks,
Yilun
> ---
> drivers/fpga/dfl-fme-perf.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> ---
> - This fix patch is not tested (as I don't have required environment).
> But issue mentioned in the commit msg can be re-created, by starting any
> fme_perf event and while its still running, offline current designated
> cpu pointed by cpumask file. Since current code didn't migrating pmu,
> perf gonna try getting counts from that offlined cpu and hence we will
> not get event data.
> ---
> diff --git a/drivers/fpga/dfl-fme-perf.c b/drivers/fpga/dfl-fme-perf.c
> index 4299145ef347..b9a54583e505 100644
> --- a/drivers/fpga/dfl-fme-perf.c
> +++ b/drivers/fpga/dfl-fme-perf.c
> @@ -953,6 +953,10 @@ static int fme_perf_offline_cpu(unsigned int cpu, struct hlist_node *node)
> return 0;
>
> priv->cpu = target;
> +
> + /* Migrate fme_perf pmu events to the new target cpu */
> + perf_pmu_migrate_context(&priv->pmu, cpu, target);
> +
> return 0;
> }
>
> --
> 2.31.1
^ permalink raw reply
* Re: [PATCH 3/8] powerpc/64s: add a table of implicit soft-masked addresses
From: Sachin Sant @ 2021-06-28 14:26 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: linuxppc-dev
In-Reply-To: <20210628074932.1499554-4-npiggin@gmail.com>
> On 28-Jun-2021, at 1:19 PM, Nicholas Piggin <npiggin@gmail.com> wrote:
>
> Commit 9d1988ca87dd ("powerpc/64: treat low kernel text as irqs
> soft-masked") ends up catching too much code, including ret_from_fork,
> and parts of interrupt and syscall return that do not expect to be
> interrupts to be soft-masked. If an interrupt gets marked pending,
> and then the code proceeds out of the implicit soft-masked region it
> will fail to deal with the pending interrupt.
>
> Fix this by adding a new table of addresses which explicitly marks
> the regions of code that are soft masked. This table is only checked
> for interrupts that below __end_soft_masked, so most kernel interrupts
> will not have the overhead of the table search.
>
> Fixes: 9d1988ca87dd ("powerpc/64: treat low kernel text as irqs soft-masked")
> Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Thanks Nick for the fix.
I was able to verify this patch.
Both kernel boot and test ran to completion without the reported warning.
Tested-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
-Sachin
^ permalink raw reply
* Re: [PATCH] perf vendor events power10: Adds 24x7 nest metric events for power10 platform
From: Paul A. Clarke @ 2021-06-28 14:30 UTC (permalink / raw)
To: kajoljain
Cc: ravi.bangoria, atrajeev, rnsastry, jolsa, linux-kernel, acme,
linux-perf-users, maddy, linuxppc-dev
In-Reply-To: <d2eaebb6-7cd6-d2e3-0bed-0c054e7d2207@linux.ibm.com>
On Mon, Jun 28, 2021 at 11:58:54AM +0530, kajoljain wrote:
>
>
> On 6/25/21 6:51 PM, Paul A. Clarke wrote:
> > On Fri, Jun 25, 2021 at 05:29:48PM +0530, Kajol Jain wrote:
> >> Patch adds 24x7 nest metric events for POWER10.
> >>
> >> Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
> >> ---
> >> .../arch/powerpc/power10/nest_metrics.json | 491 ++++++++++++++++++
> >> 1 file changed, 491 insertions(+)
> >> create mode 100644 tools/perf/pmu-events/arch/powerpc/power10/nest_metrics.json
> >>
> >> diff --git a/tools/perf/pmu-events/arch/powerpc/power10/nest_metrics.json b/tools/perf/pmu-events/arch/powerpc/power10/nest_metrics.json
> >> new file mode 100644
> >> index 000000000000..b79046cd8b09
> >> --- /dev/null
> >> +++ b/tools/perf/pmu-events/arch/powerpc/power10/nest_metrics.json
> >> @@ -0,0 +1,491 @@
> >> +[
> >> + {
> >> + "MetricName": "VEC_GROUP_PUMP_RETRY_RATIO_P01",
> >> + "BriefDescription": "VEC_GROUP_PUMP_RETRY_RATIO_P01",
> >
> > Is it possible to get better descriptions than just a restatement of the
> > name, or no description at all?
> >
> > This comment obviously applies to almost all of the metrics herein.
>
> Hi Paul,
> Thanks for reviewing the patch. Sure I will remove description part for now.
My sentence didn't parse well, sorry...
What I really meant was more like "Is it possible to get better descriptions?
Having just a restatement of the name (or no description at all in some cases)
is not helpful."
So, can we provide better descriptions of the metrics?
PC
^ permalink raw reply
* Re: [PATCH 5/8] powerpc/64: enable MSR[EE] in irq replay pt_regs
From: Sachin Sant @ 2021-06-28 14:37 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: linuxppc-dev
In-Reply-To: <20210628074932.1499554-6-npiggin@gmail.com>
> On 28-Jun-2021, at 1:19 PM, Nicholas Piggin <npiggin@gmail.com> wrote:
>
> Similar to 2b48e96be2f9f ("powerpc/64: fix irq replay pt_regs->softe
> value"), enable MSR_EE in pt_regs->msr, which makes the regs look a
> bit more normal and allows the extra debug checks to be added to
> interrupt handler entry.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> ---
> arch/powerpc/include/asm/interrupt.h | 4 ++++
> arch/powerpc/kernel/irq.c | 1 +
> 2 files changed, 5 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/interrupt.h b/arch/powerpc/include/asm/interrupt.h
> index 789311d1e283..d4bdf7d274ac 100644
> --- a/arch/powerpc/include/asm/interrupt.h
> +++ b/arch/powerpc/include/asm/interrupt.h
> @@ -173,6 +173,8 @@ static inline void interrupt_enter_prepare(struct pt_regs *regs, struct interrup
> BUG_ON(search_kernel_restart_table(regs->nip));
> #endif
> }
> + if (IS_ENABLED(CONFIG_PPC_IRQ_SOFT_MASK_DEBUG))
> + BUG_ON(!arch_irq_disabled_regs(regs) && !(regs->msr & MSR_EE));
> #endif
I think this BUG_ON was triggered while running selftests (powerpc/mm/pkey_exec_prot)
[ 9741.254969] ------------[ cut here ]------------
[ 9741.254978] kernel BUG at arch/powerpc/include/asm/interrupt.h:177!
[ 9741.254985] Oops: Exception in kernel mode, sig: 5 [#1]
[ 9741.254990] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
[ 9741.254995] Modules linked in: rpadlpar_io rpaphp uinput sha512_generic vmac n_gsm pps_ldisc pps_core ppp_synctty ppp_async ppp_generic slcan slip slhc snd_hrtimer snd_seq snd_seq_device snd_timer snd soundcore authenc pcrypt crypto_user n_hdlc dummy veth nfsv3 nfs_acl nfs lockd grace fscache netfs tun brd overlay vfat fat btrfs blake2b_generic xor zstd_compress raid6_pq xfs loop sctp ip6_udp_tunnel udp_tunnel dm_mod bonding nft_ct nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set rfkill nf_tables libcrc32c nfnetlink sunrpc pseries_rng xts vmx_crypto uio_pdrv_genirq uio sch_fq_codel ip_tables ext4 mbcache jbd2 sr_mod sd_mod cdrom t10_pi sg ibmvscsi ibmveth scsi_transport_srp fuse [last unloaded: test_cpuidle_latency]
[ 9741.255097] CPU: 17 PID: 3278920 Comm: pkey_exec_prot Tainted: G W OE 5.13.0-rc7-next-20210625-dirty #4
[ 9741.255106] NIP: c0000000000300d8 LR: c000000000009604 CTR: c000000000009330
[ 9741.255111] REGS: c0000000347536f0 TRAP: 0700 Tainted: G W OE (5.13.0-rc7-next-20210625-dirty)
[ 9741.255117] MSR: 8000000000021033 <SF,ME,IR,DR,RI,LE> CR: 22004282 XER: 20040000
[ 9741.255130] CFAR: c00000000003007c IRQMASK: 3
[ 9741.255130] GPR00: c000000000093cd0 c000000034753990 c0000000029bbe00 c000000034753a30
[ 9741.255130] GPR04: 00007fff9ebb0000 0000000000200000 000000000000000a 000000000000002d
[ 9741.255130] GPR08: 0000000000000000 0000000000000001 0000000000000000 7265677368657265
[ 9741.255130] GPR12: 8000000000021033 c00000001ec27280 0000000000000000 0000000000000000
[ 9741.255130] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 9741.255130] GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000010003c40
[ 9741.255130] GPR24: 0000000000000000 0000000000000000 0000000000200000 c00000005e89d200
[ 9741.255130] GPR28: 0000000000000300 00007fff9ebb0000 c000000034753e80 c000000034753a30
[ 9741.255191] NIP [c0000000000300d8] program_check_exception+0xe8/0x1c0
[ 9741.255202] LR [c000000000009604] program_check_common_virt+0x2d4/0x320
[ 9741.255209] Call Trace:
[ 9741.255212] [c000000034753990] [0000000000000008] 0x8 (unreliable)
[ 9741.255219] [c0000000347539c0] [c000000034753a80] 0xc000000034753a80
[ 9741.255225] --- interrupt: 700 at arch_local_irq_restore+0x1d0/0x200
[ 9741.255231] NIP: c000000000016790 LR: c000000000093388 CTR: c000000000008780
[ 9741.255236] REGS: c000000034753a30 TRAP: 0700 Tainted: G W OE (5.13.0-rc7-next-20210625-dirty)
[ 9741.255242] MSR: 8000000000021033 <SF,ME,IR,DR,RI,LE> CR: 24004288 XER: 20040000
[ 9741.255253] CFAR: c0000000000165ec IRQMASK: 0
[ 9741.255253] GPR00: c000000000093cd0 c000000034753cd0 c0000000029bbe00 0000000000000000
[ 9741.255253] GPR04: 00007fff9ebb0000 0000000000200000 000000000000000a 000000000000002d
[ 9741.255253] GPR08: 0000000000000000 0000000000000000 c0000000bd77d400 7265677368657265
[ 9741.255253] GPR12: 0000000044000282 c00000001ec27280 0000000000000000 0000000000000000
[ 9741.255253] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 9741.255253] GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000010003c40
[ 9741.255253] GPR24: 0000000000000000 0000000000000000 0000000000200000 c00000005e89d200
[ 9741.255253] GPR28: 0000000000000300 00007fff9ebb0000 c000000034753e80 0000000000000001
[ 9741.255313] NIP [c000000000016790] arch_local_irq_restore+0x1d0/0x200
[ 9741.255319] LR [c000000000093388] ___do_page_fault+0x438/0xb80
[ 9741.255325] --- interrupt: 700
[ 9741.255328] [c000000034753cd0] [c00000000009be74] hash_page_mm+0x5e4/0x800 (unreliable)
[ 9741.255335] [c000000034753d00] [000000000000002d] 0x2d
[ 9741.255340] [c000000034753db0] [c000000000093cd0] hash__do_page_fault+0x30/0x70
[ 9741.255348] [c000000034753de0] [c00000000009c438] do_hash_fault+0x78/0xb0
[ 9741.255354] [c000000034753e10] [c00000000000891c] data_access_common_virt+0x19c/0x1f0
[ 9741.255361] --- interrupt: 300 at 0x10001e8c
[ 9741.255365] NIP: 0000000010001e8c LR: 0000000010001e84 CTR: 00007fff9ea4eb60
[ 9741.255370] REGS: c000000034753e80 TRAP: 0300 Tainted: G W OE (5.13.0-rc7-next-20210625-dirty)
[ 9741.255376] MSR: 800000000280f033 <SF,VEC,VSX,EE,PR,FP,ME,IR,DR,RI,LE> CR: 28000282 XER: 20040000
[ 9741.255391] CFAR: c00000000000ca44 DAR: 00007fff9ebb0000 DSISR: 00200000 IRQMASK: 0
[ 9741.255391] GPR00: 0000000010001e84 00007fffd11fa7b0 0000000010027f00 0000000000000033
[ 9741.255391] GPR04: 0000000010003c3d 0000000000000001 000000000000000a 000000000000002d
[ 9741.255391] GPR08: 0000000000000000 00007fff9ebb0000 0000000000000000 000001002ab20337
[ 9741.255391] GPR12: 0000000000000000 00007fff9ec4a270 0000000000000000 0000000000000000
[ 9741.255391] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 9741.255391] GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000010003c40
[ 9741.255391] GPR24: 0000000000000001 0000000010003c18 000000000000002d 0000000010020160
[ 9741.255391] GPR28: 00c0000000000000 0000000010020230 0000000000000002 0000000000000004
[ 9741.255455] NIP [0000000010001e8c] 0x10001e8c
[ 9741.255459] LR [0000000010001e84] 0x10001e84
[ 9741.255463] --- interrupt: 300
[ 9741.255466] Instruction dump:
[ 9741.255470] 60000000 e8010040 7c6a1b78 7c0803a6 0b0a0000 e93f0138 71290001 4082004c
[ 9741.255481] e95f0108 39200001 714a8000 4082ff68 <0b090000> 38210030 7fe3fb78 ebe1fff8
[ 9741.255494] ---[ end trace c668c70ea0d5061f ]—
Thanks
-Sachin
>
> booke_restore_dbcr0();
> @@ -268,6 +270,8 @@ static inline void interrupt_nmi_enter_prepare(struct pt_regs *regs, struct inte
> // arch_irq_disabled_regs(regs) behaves as expected.
> regs->softe = IRQS_ALL_DISABLED;
> }
> + if (IS_ENABLED(CONFIG_PPC_IRQ_SOFT_MASK_DEBUG))
> + BUG_ON(!arch_irq_disabled_regs(regs) && !(regs->msr & MSR_EE));
>
> /* Don't do any per-CPU operations until interrupt state is fixed */
>
> diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
> index 8428caf3194e..91e63eac4e8f 100644
> --- a/arch/powerpc/kernel/irq.c
> +++ b/arch/powerpc/kernel/irq.c
> @@ -121,6 +121,7 @@ void replay_soft_interrupts(void)
>
> ppc_save_regs(®s);
> regs.softe = IRQS_ENABLED;
> + regs.msr |= MSR_EE;
>
> again:
> if (IS_ENABLED(CONFIG_PPC_IRQ_SOFT_MASK_DEBUG))
> --
> 2.23.0
>
^ permalink raw reply
* Re: [PATCH] perf script python: Fix buffer size to report iregs in perf script
From: Paul A. Clarke @ 2021-06-28 14:49 UTC (permalink / raw)
To: Kajol Jain
Cc: ravi.bangoria, atrajeev, rnsastry, linuxppc-dev, linux-kernel,
acme, linux-perf-users, maddy, jolsa
In-Reply-To: <20210628062341.155839-1-kjain@linux.ibm.com>
On Mon, Jun 28, 2021 at 11:53:41AM +0530, Kajol Jain wrote:
> Commit 48a1f565261d ("perf script python: Add more PMU fields
> to event handler dict") added functionality to report fields like
> weight, iregs, uregs etc via perf report.
> That commit predefined buffer size to 512 bytes to print those fields.
>
> But incase of powerpc, since we added extended regs support
> in commits:
>
> Commit 068aeea3773a ("perf powerpc: Support exposing Performance Monitor
> Counter SPRs as part of extended regs")
> Commit d735599a069f ("powerpc/perf: Add extended regs support for
> power10 platform")
>
> Now iregs can carry more bytes of data and this predefined buffer size
> can result to data loss in perf script output.
>
> Patch resolve this issue by making buffer size dynamic based on number
> of registers needed to print. It also changed return type for function
> "regs_map" from int to void, as the return value is not being used by
> the caller function "set_regs_in_dict".
>
> Fixes: 068aeea3773a ("perf powerpc: Support exposing Performance Monitor
> Counter SPRs as part of extended regs")
> Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
> ---
> .../util/scripting-engines/trace-event-python.c | 17 ++++++++++++-----
> 1 file changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/tools/perf/util/scripting-engines/trace-event-python.c b/tools/perf/util/scripting-engines/trace-event-python.c
> index 4e4aa4c97ac5..c8c9706b4643 100644
> --- a/tools/perf/util/scripting-engines/trace-event-python.c
> +++ b/tools/perf/util/scripting-engines/trace-event-python.c
[...]
> @@ -713,7 +711,16 @@ static void set_regs_in_dict(PyObject *dict,
> struct evsel *evsel)
> {
> struct perf_event_attr *attr = &evsel->core.attr;
> - char bf[512];
> +
> + /*
> + * Here value 28 is a constant size which can be used to print
> + * one register value and its corresponds to:
> + * 16 chars is to specify 64 bit register in hexadecimal.
> + * 2 chars is for appending "0x" to the hexadecimal value and
> + * 10 chars is for register name.
> + */
> + int size = __sw_hweight64(attr->sample_regs_intr) * 28;
> + char bf[size];
I propose using a template rather than a magic number here. Something like:
const char reg_name_tmpl[] = "10 chars ";
const char reg_value_tmpl[] = "0x0123456789abcdef";
const int size = __sw_hweight64(attr->sample_regs_intr) +
sizeof reg_name_tmpl + sizeof reg_value_tmpl;
Pardon my ignorance, but is there no separation/whitespace between the name
and the value? And is there some significance to 10 characters for the
register name, or is that a magic number?
PC
^ permalink raw reply
* [PATCH v5 0/6] Add support for FORM2 associativity
From: Aneesh Kumar K.V @ 2021-06-28 15:11 UTC (permalink / raw)
To: linuxppc-dev, mpe
Cc: Nathan Lynch, Aneesh Kumar K.V, Daniel Henrique Barboza,
David Gibson
Form2 associativity adds a much more flexible NUMA topology layout
than what is provided by Form1. More details can be found in patch 7.
$ numactl -H
...
node distances:
node 0 1 2 3
0: 10 11 222 33
1: 44 10 55 66
2: 77 88 10 99
3: 101 121 132 10
$
After DAX kmem memory add
# numactl -H
available: 5 nodes (0-4)
...
node distances:
node 0 1 2 3 4
0: 10 11 222 33 240
1: 44 10 55 66 255
2: 77 88 10 99 255
3: 101 121 132 10 230
4: 255 255 255 230 10
PAPR SCM now use the numa distance details to find the numa_node and target_node
for the device.
kvaneesh@ubuntu-guest:~$ ndctl list -N -v
[
{
"dev":"namespace0.0",
"mode":"devdax",
"map":"dev",
"size":1071644672,
"uuid":"d333d867-3f57-44c8-b386-d4d3abdc2bf2",
"raw_uuid":"915361ad-fe6a-42dd-848f-d6dc9f5af362",
"daxregion":{
"id":0,
"size":1071644672,
"devices":[
{
"chardev":"dax0.0",
"size":1071644672,
"target_node":4,
"mode":"devdax"
}
]
},
"align":2097152,
"numa_node":3
}
]
kvaneesh@ubuntu-guest:~$
The above output is with a Qemu command line
-numa node,nodeid=4 \
-numa dist,src=0,dst=1,val=11 -numa dist,src=0,dst=2,val=222 -numa dist,src=0,dst=3,val=33 -numa dist,src=0,dst=4,val=240 \
-numa dist,src=1,dst=0,val=44 -numa dist,src=1,dst=2,val=55 -numa dist,src=1,dst=3,val=66 -numa dist,src=1,dst=4,val=255 \
-numa dist,src=2,dst=0,val=77 -numa dist,src=2,dst=1,val=88 -numa dist,src=2,dst=3,val=99 -numa dist,src=2,dst=4,val=255 \
-numa dist,src=3,dst=0,val=101 -numa dist,src=3,dst=1,val=121 -numa dist,src=3,dst=2,val=132 -numa dist,src=3,dst=4,val=230 \
-numa dist,src=4,dst=0,val=255 -numa dist,src=4,dst=1,val=255 -numa dist,src=4,dst=2,val=255 -numa dist,src=4,dst=3,val=230 \
-object memory-backend-file,id=memnvdimm1,prealloc=yes,mem-path=$PMEM_DISK,share=yes,size=${PMEM_SIZE} \
-device nvdimm,label-size=128K,memdev=memnvdimm1,id=nvdimm1,slot=4,uuid=72511b67-0b3b-42fd-8d1d-5be3cae8bcaa,node=4
Qemu changes can be found at https://lore.kernel.org/qemu-devel/20210616011944.2996399-1-danielhb413@gmail.com/
Changes from v4:
* Drop DLPAR related device tree property for now because both Qemu nor PowerVM
will provide the distance details of all possible NUMA nodes during boot.
* Rework numa distance code based on review feedback.
Changes from v3:
* Drop PAPR SCM specific changes and depend completely on NUMA distance information.
Changes from v2:
* Add nvdimm list to Cc:
* update PATCH 8 commit message.
Changes from v1:
* Update FORM2 documentation.
* rename max_domain_index to max_associativity_domain_index
Aneesh Kumar K.V (6):
powerpc/pseries: rename min_common_depth to primary_domain_index
powerpc/pseries: rename distance_ref_points_depth to
max_associativity_domain_index
powerpc/pseries: Rename TYPE1_AFFINITY to FORM1_AFFINITY
powerpc/pseries: Consolidate different NUMA distance update code paths
powerpc/pseries: Add a helper for form1 cpu distance
powerpc/pseries: Add support for FORM2 associativity
Documentation/powerpc/associativity.rst | 103 +++++
arch/powerpc/include/asm/firmware.h | 7 +-
arch/powerpc/include/asm/prom.h | 3 +-
arch/powerpc/include/asm/topology.h | 4 +-
arch/powerpc/kernel/prom_init.c | 3 +-
arch/powerpc/mm/numa.c | 415 +++++++++++++-----
arch/powerpc/platforms/pseries/firmware.c | 3 +-
arch/powerpc/platforms/pseries/hotplug-cpu.c | 2 +
.../platforms/pseries/hotplug-memory.c | 2 +
arch/powerpc/platforms/pseries/lpar.c | 4 +-
arch/powerpc/platforms/pseries/pseries.h | 1 +
11 files changed, 432 insertions(+), 115 deletions(-)
create mode 100644 Documentation/powerpc/associativity.rst
--
2.31.1
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox