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 16CD031ED7F for ; Tue, 6 Jan 2026 11:21:27 +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=1767698489; cv=none; b=jMcqzh+z0KM7P3mI4jA5ixc+qrL1WCzbBk3kG5L4wAS1YrUkZGsuhDmBZ8VJ9CdXcX356kYMeEz3DfuV6qM0QiJEBgNF0eERgDBOLhgF4TWRnYjSsbErj3UDLkWu3wbJfz8sok6QXs6dg2KyQXzlZAz5CmP246AqqYpjDKSodIo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767698489; c=relaxed/simple; bh=HtVQxGqxmycZRrMSpUGFDno6BjtIe7FZF0i2ITi6/3E=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=o0rG3w99jgb8nvrfQITr7R75G78boen/fQ61WqG9CpgZKCErsRE0iWH1naKFFIY2RnlrbpsExs8l/ccgwpDkUD1HzxK3/q8I+QjfUenwCAw9/fiysWrgf3U3yYTZ9wUbDZOGBwqHq3JCdnUJEat8oZKGszY55NXmVPgpe2NEN6g= 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 93F3C1596; Tue, 6 Jan 2026 03:21:20 -0800 (PST) Received: from [10.1.196.46] (e134344.arm.com [10.1.196.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8F8D83F5A1; Tue, 6 Jan 2026 03:21:22 -0800 (PST) Message-ID: <22eadfd1-67f9-470f-8e4e-b9af4dc869e1@arm.com> Date: Tue, 6 Jan 2026 11:21:20 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 22/45] arm_mpam: resctrl: Add CDP emulation To: Jonathan Cameron Cc: amitsinght@marvell.com, baisheng.gao@unisoc.com, baolin.wang@linux.alibaba.com, carl@os.amperecomputing.com, dave.martin@arm.com, david@kernel.org, dfustini@baylibre.com, fenghuay@nvidia.com, gshan@redhat.com, james.morse@arm.com, kobak@nvidia.com, lcherian@marvell.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, peternewman@google.com, punit.agrawal@oss.qualcomm.com, quic_jiles@quicinc.com, reinette.chatre@intel.com, rohit.mathew@arm.com, scott@os.amperecomputing.com, sdonthineni@nvidia.com, tan.shaopeng@fujitsu.com, xhao@linux.alibaba.com, catalin.marinas@arm.com, will@kernel.org, corbet@lwn.net, maz@kernel.org, oupton@kernel.org, joey.gouly@arm.com, suzuki.poulose@arm.com, kvmarm@lists.linux.dev References: <20251219181147.3404071-1-ben.horgan@arm.com> <20251219181147.3404071-23-ben.horgan@arm.com> <20260105180700.000037c8@huawei.com> From: Ben Horgan Content-Language: en-US In-Reply-To: <20260105180700.000037c8@huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Jonathan, On 1/5/26 18:07, Jonathan Cameron wrote: > On Fri, 19 Dec 2025 18:11:24 +0000 > Ben Horgan wrote: > >> From: James Morse >> >> Intel RDT's CDP feature allows the cache to use a different control value >> depending on whether the accesses was for instruction fetch or a data >> access. MPAM's equivalent feature is the other way up: the CPU assigns a >> different partid label to traffic depending on whether it was instruction >> fetch or a data access, which causes the cache to use a different control >> value based solely on the partid. >> >> MPAM can emulate CDP, with the side effect that the alternative partid is >> seen by all MSC, it can't be enabled per-MSC. >> >> Add the resctrl hooks to turn this on or off. Add the helpers that match a >> closid against a task, which need to be aware that the value written to >> hardware is not the same as the one resctrl is using. >> >> Update the 'arm64_mpam_global_default' variable the arch code uses during >> context switch to know when the per-cpu value should be used instead. >> >> Awkwardly, the MB controls don't implement CDP. To emulate this, the MPAM >> equivalent needs programming twice by the resctrl glue, as resctrl expects >> the bandwidth controls to be applied independently for both data and >> instruction-fetch. >> >> CC: Dave Martin >> CC: Amit Singh Tomar >> Signed-off-by: James Morse >> Signed-off-by: Ben Horgan > > Minor thing below. > Reviewed-by: Jonathan Cameron > > >> diff --git a/include/linux/arm_mpam.h b/include/linux/arm_mpam.h >> index 5a78299ec464..ba0312b55d9f 100644 >> --- a/include/linux/arm_mpam.h >> +++ b/include/linux/arm_mpam.h >> @@ -5,6 +5,7 @@ >> #define __LINUX_ARM_MPAM_H >> >> #include >> +#include > > This seems odd as nothing added to the header in this path appears to need it. > Maybe should be down in the c file or in a different patch? Yep, moved it to patch 33, arm_mpam: resctrl: Allow resctrl to allocate monitors. > >> #include >> >> struct mpam_msc; >> @@ -56,6 +57,8 @@ void resctrl_arch_set_cpu_default_closid(int cpu, u32 closid); >> void resctrl_arch_set_closid_rmid(struct task_struct *tsk, u32 closid, u32 rmid); >> void resctrl_arch_set_cpu_default_closid_rmid(int cpu, u32 closid, u32 rmid); >> void resctrl_arch_sched_in(struct task_struct *tsk); >> +bool resctrl_arch_match_closid(struct task_struct *tsk, u32 closid); >> +bool resctrl_arch_match_rmid(struct task_struct *tsk, u32 closid, u32 rmid); >> >> /** >> * mpam_register_requestor() - Register a requestor with the MPAM driver > Thanks, Ben