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 2BAAD34C815 for ; Tue, 16 Dec 2025 13:49:22 +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=1765892966; cv=none; b=YRWXMQ/+Ip2rNxAAc1vuRksHccAkWrVtVTkKq0zE7M++AnRYROQAyTzsd+ZCuUqd4LGedEV4aWCs804RHkA/3b0yP+5tBW0NJoS0Q/qIV23muNCZXAS8qBmhLrEX5E4QOYOB/iS4gjb6w58qshIE+djZTHA1AAANLl13g5412No= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765892966; c=relaxed/simple; bh=1QzgiJosBVmR9V+pUf7R0HdawfQjCgOPcx/uqlogqks=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=GHj7apsBMmXdj7rFWmTG312fDd9S9+rTyaMWeY7gYiqzWlIfOk6s2qR4ijy/dA456uvpsrwJWQVcpMgw5xqrlycMxkbFICKDa2BA22qtxaadOdDbPdhZps/hCpMaaqOY1Rug+CP/D/gexBOM1w/2J3OCQmfpW612G5Z36/Tc9wY= 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 023F4FEC; Tue, 16 Dec 2025 05:49:15 -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 CF4C13F73B; Tue, 16 Dec 2025 05:49:18 -0800 (PST) Message-ID: <6c652963-eda0-416b-b1b3-98c5313ed5fc@arm.com> Date: Tue, 16 Dec 2025 13:49:17 +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: [RFC PATCH 13/38] arm_mpam: resctrl: Add CDP emulation To: James Morse , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Cc: D Scott Phillips OS , carl@os.amperecomputing.com, lcherian@marvell.com, bobo.shaobowang@huawei.com, tan.shaopeng@fujitsu.com, baolin.wang@linux.alibaba.com, Jamie Iles , Xin Hao , peternewman@google.com, dfustini@baylibre.com, amitsinght@marvell.com, David Hildenbrand , Dave Martin , Koba Ko , Shanker Donthineni , fenghuay@nvidia.com, baisheng.gao@unisoc.com, Jonathan Cameron , Gavin Shan , rohit.mathew@arm.com, reinette.chatre@intel.com, Punit Agrawal References: <20251205215901.17772-1-james.morse@arm.com> <20251205215901.17772-14-james.morse@arm.com> From: Ben Horgan Content-Language: en-US In-Reply-To: <20251205215901.17772-14-james.morse@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi James, On 12/5/25 21:58, James Morse wrote: > 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 isntruction-fetch. > > CC: Dave Martin > CC: Ben Horgan > CC: Amit Singh Tomar > Signed-off-by: James Morse > --- > arch/arm64/include/asm/mpam.h | 1 + > drivers/resctrl/mpam_resctrl.c | 115 ++++++++++++++++++++++++++++++++- > include/linux/arm_mpam.h | 3 + > 3 files changed, 118 insertions(+), 1 deletion(-) > [...] > > @@ -272,6 +369,7 @@ u32 resctrl_arch_get_config(struct rdt_resource *r, struct rdt_ctrl_domain *d, > int resctrl_arch_update_one(struct rdt_resource *r, struct rdt_ctrl_domain *d, > u32 closid, enum resctrl_conf_type t, u32 cfg_val) > { > + int err; > u32 partid; > struct mpam_config cfg; > struct mpam_props *cprops; > @@ -311,7 +409,22 @@ int resctrl_arch_update_one(struct rdt_resource *r, struct rdt_ctrl_domain *d, > return -EINVAL; > } > > - return mpam_apply_config(dom->ctrl_comp, partid, &cfg); > + /* > + * When CDP is enabled, but the resource doesn't support it, we need to > + * apply the same configuration to the other partid. > + */ > + if (mpam_resctrl_hide_cdp(r->rid)) { > + partid = resctrl_get_config_index(closid, CDP_CODE); > + err = mpam_apply_config(dom->ctrl_comp, partid, &cfg); > + if (err) > + return err; > + > + partid = resctrl_get_config_index(closid, CDP_DATA); > + return mpam_apply_config(dom->ctrl_comp, partid, &cfg); This is indeed awkward. As we are programming twice, if instruction and data use b/w equally then the MB setting will be as if it was double. However, if we halved the configured value, and most of the bandwidth was for data, then it would be as if it was halved. For controls where the actual parts are chosen, rather than just the size then this programming twice will work as expected. Therefore, I think your chosen policy is the least surprising and I'll keep this as is. > + > + } else { > + return mpam_apply_config(dom->ctrl_comp, partid, &cfg); > + } > } [...] Thanks, Ben