| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <0a84f8ce-80a3-c49a-28a1-0d3c5e8839fa@huawei.com> Date: Thu, 19 Dec 2024 21:39:50 +0800 From: Zeng Heng <zengheng4@...wei.com> To: Dave Martin <Dave.Martin@....com> CC: <james.morse@....com>, <linux-kernel@...r.kernel.org>, <linux-arm-kernel@...ts.infradead.org>, <jonathan.cameron@...wei.com>, <xiexiuqi@...wei.com>, "Wangshaobo (bobo)" <bobo.shaobowang@...wei.com> Subject: Re: [RFC PATCH mpam mpam/snapshot/v6.12-rc1 v3 2/5] arm_mpam: Read monitor value with new closid/rmid pair On 2024/12/13 0:18, Dave Martin wrote: > Hi, > > On Sat, Dec 07, 2024 at 05:21:33PM +0800, Zeng Heng wrote: >> The MPAM driver statically assigns all reqPARTIDs to respective intPARTIDs. >> For the new rmid allocation strategy, it will check if there is an >> available rmid of any reqPARTID which belongs to the input closid, not just >> the rmids belonging to the closid. >> >> For a mixture of MSCs system, for MSCs that do not support narrow-partid, >> we use the PARTIDs exceeding the number of closids as reqPARTIDs for >> expanding the monitoring groups. >> >> In order to keep the existing resctrl API interface, the rmid contains both >> req_idx and PMG information instead of PMG only under the MPAM driver. The >> req_idx represents the req_idx-th sub-monitoring group under the control >> group. The new rmid would be like: >> >> rmid = (req_idx << shift | pmg). >> >> The mapping relationships between each group's closid/rmid and the >> respective MSCs' intPARTID/reqPARTID/PARTID are illustrated: >> >> n - Indicates the total number of intPARTIDs >> m - Indicates the number of reqPARTIDs per intPARTID >> >> P - Partition group (control group) >> M - Monitoring group >> >> Group closid rmid.req_idx (req)PARTID MSCs with narrow-partid MSCs without narrow-partid >> P1 0 - 0 intPARTID_1 PARTID_1 >> M1_1 0 0 0 ├── reqPARTID_1_1 ├── PARTID_1_1 >> M1_2 0 1 0+n ├── reqPARTID_1_2 ├── PARTID_1_2 >> M1_3 0 2 0+n*2 ├── reqPARTID_1_3 ├── PARTID_1_3 >> ... ├── ... ├── ... >> M1_m 0 (m-1) 0+n*(m-1) └── reqPARTID_1_m └── PARTID_1_m >> >> P2 1 - 1 intPARTID_2 PARTID_2 >> M2_1 1 0 1 ├── reqPARTID_2_1 ├── PARTID_2_1 >> M2_2 1 1 1+n ├── reqPARTID_2_2 ├── PARTID_2_2 >> M2_3 1 2 1+n*2 ├── reqPARTID_2_3 ├── PARTID_2_3 >> ... ├── ... ├── ... >> M2_m 1 (m-1) 1+n*(m-1) └── reqPARTID_2_m └── PARTID_2_m >> >> Pn (n-1) - (n-1) intPARTID_n PARTID_n >> Mn_1 (n-1) 0 (n-1) ├── reqPARTID_n_1 ├── PARTID_n_1 >> Mn_2 (n-1) 1 (n-1)+n ├── reqPARTID_n_2 ├── PARTID_n_2 >> Mn_3 (n-1) 2 (n-1)+n*2 ├── reqPARTID_n_3 ├── PARTID_n_3 >> ... ├── ... ├── ... >> Mn_m (n-1) (m-1) (n-1)+n*(m-1) = n*m-1 └── reqPARTID_n_m └── PARTID_n_m >> >> Based on the example provided, the conversion relationship between >> closid/rmid and (req)PARTID/PMG is: >> >> (req)PARTID = (rmid.req_idx * n) + closid, >> PMG = rmid.pmg. > > It seemed more natural to me for the PARTIDs assigned to a particular > CLOSID to be consecutively numbered (see [1]), though it works either > way. > > Otherwise, the approach makes sense. Yes, I agree with your point and it would be included in the next version soon. Best Regards, Zeng Heng
Powered by blists - more mailing lists