From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 0BDD41C1753 for ; Fri, 3 Jan 2025 15:31:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735918307; cv=none; b=NP4yL4iFddMfwFp0b/K6shCeo+f9Wcca3wf8VMQF4mmcnw6qJUvFlo0vMwPCmelPEjnVXMXbHpSa3WB6f00ju5UkdukExAy8tDhWCA7x8snOA+ZJKPvvkf06kp95dVw4M4MjBtBULwaHIGaDoaRzdE1qnb6N+sUtCo7g0W91iqo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735918307; c=relaxed/simple; bh=KxhTP65zdZZhWTJ4Yoqssu9hlKuITGn9eORsW8i+6bI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=bmXHdZy4zzagEp6qv3MfZpl0Brnmw0s2T6KJ0nxL/8ZYdcRTP6cB+KfG3YX3NmgRRRXt4/FaVX88KvYxBnQJRZ+aA0B2il9ac3CmQY2qt7/h+BMzMzpa2Iy1zxarIBpW1A9Gn2g1Kpbq/JZxj5x/j3/o4erIqOdWSp6tMS0Pf6Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id EBAA51480; Fri, 3 Jan 2025 07:32:11 -0800 (PST) Received: from e133380.arm.com (e133380.arm.com [10.1.197.41]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 72DA63F6A8; Fri, 3 Jan 2025 07:31:42 -0800 (PST) Date: Fri, 3 Jan 2025 15:31:39 +0000 From: Dave Martin To: Zeng Heng Cc: james.morse@arm.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, jonathan.cameron@huawei.com, xiexiuqi@huawei.com, "Wangshaobo (bobo)" Subject: Re: [RFC PATCH mpam mpam/snapshot/v6.12-rc1 v3 2/5] arm_mpam: Read monitor value with new closid/rmid pair Message-ID: References: <20241207092136.2488426-1-zengheng4@huawei.com> <20241207092136.2488426-3-zengheng4@huawei.com> <8fa84731-1ae6-e40f-3594-3241b1ee8bb4@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8fa84731-1ae6-e40f-3594-3241b1ee8bb4@huawei.com> On Fri, Jan 03, 2025 at 02:55:17PM +0800, Zeng Heng wrote: > > > On 2024/12/13 0:18, Dave Martin wrote: > > Hi, > > > > On Sat, Dec 07, 2024 at 05:21:33PM +0800, Zeng Heng wrote: [...] > > > 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. > > > > > After attempting to change the mapping method in practice, I found that > there are some following advantages of the current method which keeps > intPARTIDs are mapped to the first n IDs: Thanks for having a go. > 1. Because closid is exactly equal to intPARTID, and the conversion > relationship between closid and intPARTID remains unchanged under the > current method (still only call the resctrl_get_config_index() for > conversion), maintaining the original semantics during the MPAM > configuration updating; You are right about this, but I think this is just moving complexity around rather than eliminating it? I've tried various approaches, and there there always seems to be one ugly step somewhere; either something in mpam_devices.c that feels like it should be in mpam_resctrl.c, or something in mpam_resctrl.c that feels like it should be in mpam_devices.c. > 2. Since there is no need to create a new transformation (like > closid2intpartid()) between closid and intPARTID, this can reduce the > work of function adaptations, such as in resctrl_arch_update_one(), > resctrl_arch_get_config(), and so on, which doesn't need any extra > adaptions and keeps things as simple as possible. > > Looking forward to your comments. > > > Greeting for new year, > Zeng Heng > Happy New Year to you too! What you say is true, but I think the runtime cost of the conversions is going to be trivial compared with the cost of the actual MSC programming. For context: I'm hoping to factor the code so that the conversion is as cleanly separated out as possible, so that it would be straightforward to move to an arbitrary mapping in the future if it is possible to agree changes in the core resctrl interface so that the PARTID/PMG allocations can be dynamic. If we do that, the conversion would probably become a simple table lookup. This factoring seems more important than which precise mapping we choose right now. But in the interests of improving PARTID Narrowing support sooner, I think that going straight to dynamic allocation is not the best approach -- so my idea is to prepare for that on the MPAM driver side, but not prioritise developing a dynamic approach until after the resctrlfs refactoring and the MPAM driver are merged upstream. Does that make sense? Cheers ---Dave