[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d7069933-903e-9e1e-d7a4-5a6a9fa53064@huawei.com>
Date: Mon, 17 Feb 2025 14:18:44 +0800
From: Zeng Heng <zengheng4@...wei.com>
To: <Dave.Martin@....com>, <james.morse@....com>
CC: <bobo.shaobowang@...wei.com>, <jonathan.cameron@...wei.com>,
<linux-arm-kernel@...ts.infradead.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH mpam mpam/snapshot/v6.14-rc1 3/5] arm_mpam: Provide
conversion method for new closid/rmid pairs
Hi Martin,
On 2025/2/17 11:18, 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).
>
To consider future compatibility with dynamically allocated reqpartid,
should I refactor the rmid?
Instead of defining rmid.req_idx, we could place the entire reqpartid
directly within rmid. In This way, the allocation of reqpartid will no
longer be constrained by the static allocation of closid, facilitating
future compatibility with dynamic allocation mechanisms.
In this case, it needs to refactor the resctrl_arch_rmid_idx_encode()
and resctrl_arch_rmid_idx_decode(), and we can simplify
closid_rmid2reqpartid() to rmid2reqpartid().
What are your thoughts on this idea? Thank you in advance for your
reply.
Best regards,
Zeng Heng
Powered by blists - more mailing lists