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 917CF155C97 for ; Thu, 2 Jan 2025 16:46:03 +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=1735836366; cv=none; b=fsnDp2NUsrrPCwKbMxKg8lzD6BGvlakU+6JkfrzZWI7NG2iWsDbsTaaMG1B1t5FwKbTmCXrDzDNwYVm/8kfQa4rKxUE60AewCfHj3yV9XzUYc/uS2FOzkrH0ZsyXCnx5oyFwZm6rqwADjOCUpCMWCHd0xiQ9GvbvGv1E+Fvu+bw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735836366; c=relaxed/simple; bh=dRmWHtDoD2rg/Ag2s0lCaearVV0FdMWbuNha7whAFSI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=NrAbKYetA3G7iB10qB7tLyPORH7rEOD7jUpiNCom6dXw3lGfGgfYWSAGq38NSqWsA4HTi3mPkIPH72uEPh5T18JOcf7cq7TnZnm6YOyNzhJnWp6/cTnpvbq6FS0tnVlDPHEtd2mpLP7jxR+RXAUDXZP/QnhTc0lPj7ADIjUSTkI= 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 23E1F11FB; Thu, 2 Jan 2025 08:46:30 -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 C91E43F673; Thu, 2 Jan 2025 08:46:00 -0800 (PST) Date: Thu, 2 Jan 2025 16:45:58 +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 0/5] arm_mpam: Introduce the Narrow-PARTID feature for MPAM driver Message-ID: References: <20241207092136.2488426-1-zengheng4@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: On Fri, Dec 20, 2024 at 06:59:31PM +0800, Zeng Heng wrote: > > > On 2024/12/13 0:17, Dave Martin wrote: > > Hi, > > > > On Sat, Dec 07, 2024 at 05:21:31PM +0800, Zeng Heng wrote: [...] > > > 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. > > > > Mixed systems still seem not to be handled completely by this series? > > > > You do cope with the scenario where some MSCs support Narrowing and > > some do not, but there is still the problem of incompatible controls. > > > > If a non-Narrowing MSC has controls that are not of the "partition > > bitmap" type, then splitting a resctrl control group across multiple > > PARTIDs is going to change the hardware regulation behaviour. There > > does not seem to be any way to work around this be programming > > different control values (for example). So, there may be over- or > > under-allocation of resources compared with what the user requests in > > resctrlfs. > > > > So, I think there is still a need to check which controls are present, > > and either disable the use of non-identity intPARTID<->reqPARTID > > mappings if incompatible controls are present (or don't expose those > > controls to resctrl). > > > > (If you were not trying to address this issue yet then that is not a > > problem for an RFC, but it is best to be clear about the > > limitations...) > > > > In the v3, the limitation you mentioned has not yet been handled. > V3 has not yet determined how to define this limitation well. Additionally, > for v3, I was still uncertain whether a large-scale > refactoring was still necessary at that time. > > In fact, I take this limitation very seriously, and I will try to define > the limitation in next version, explaining it separately as a distinct > patch. Fair enough. I just wanted to make sure that this issue is not missed (since this is where a lot of the complexity comes from!) [...] > > This approach looks reasonable overall, and in this version the changes > > do seem to be better localised in the mpam_resctrl.c glue code now. > > > > I had also been working on a similar approach, so I have posted it for > > comparison [1] -- though the two approaches are doing pretty much the > > same thing, some details differ. > > > > (Note, I have not addressed PARTID Narrowing at all yet; however, > > I think more thought is needed for that.) > > > > Yes, localize the narrow-partid feature within mpam_resctrl.c file is > the biggest restructuring improvement in this version. Of course, thanks > for your meticulous review and insightful comments. > > In the meanwhile, I have roughly read through the patch set you sent > out, especially patch 4 (arm_mpam: Introduce flexible CLOSID/RMID > translation). If I have any comments worth discussing, I will try to > share them. I would appreciate that, thanks! > > > > > Note: Are there bisection issues with some of the patches in the > > series? It looks like not all of the ID conversions are applied in the > > same patch, so I'm wondering whether strange behaviour may be seen at > > the intermediate commits. > > > > The original intention of splitting the patch set was to facilitate review. > I will merge the part of patch 5 into patch 2 and consider > making the patch set be friendly for bisection issues. > > > Best regards, > Zeng Heng Understood. James may have a view on how important bisectability is, since this is not upstream code -- but it is probably a good idea to maintain full bisectability if at all possible. Cheers ---Dave