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 652823D3CEF for ; Fri, 3 Jul 2026 13:42:38 +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=1783086160; cv=none; b=XlwhT+mFKOlBXCwlRpZMcM9MY+HfT+XHhnqrMxA1Ap90QP8LX7QaR+NeaPcx8VozTBI2XZWAKyh+/mfGM9eIZbnrtGkrehypAgijAZ4AKIA8V6CxgfI45gGAduQpMo/xD8gME27AjnRBusxy7iDF3tiJAWlmJ0xtKHPJ5K83Hq8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783086160; c=relaxed/simple; bh=5Nw2JvX8C5V4U7NjGjJ09Aionb2v1cJEFXXXWmA2d3o=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=JWFWu6aHtfs7nzfGkGd7oLe6E/TqGi4+IgrYKfD6cJrTe4Ir3TyOwZnNkDtUfUjSws9mEiTU9MFV+TdAvaa/OqFO0y1eLLbrL9WHhN/yPtrpqmmywGHfsz++VSb+i3dZJ/w26b5a6dix3oqrgBkIhQjaopwnt/TLNZrKG7x+VXE= 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; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=ktrADbvh; 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 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="ktrADbvh" 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 9EF3F465E; Fri, 3 Jul 2026 06:42:33 -0700 (PDT) Received: from [10.211.55.3] (unknown [10.57.73.238]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 462B13F85F; Fri, 3 Jul 2026 06:42:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1783086158; bh=5Nw2JvX8C5V4U7NjGjJ09Aionb2v1cJEFXXXWmA2d3o=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=ktrADbvhYYHVsObP/QbLV8oKfOrx8j8rgML3GkfKIEeAt0HK/NA9eII3HV9I/h4VU XnCprEjjySEPLYXBGrPg1g1+MTzUr6PkOp31LDIahZ5+gqNAeg2JgUbF+zSv+2uqQ5 xSdf5Po95KoAQ1T+xoPm2U5rYtzy5Hh7ShjpwAG0= Message-ID: <074a6766-0355-409c-bad5-855498fdb7d5@arm.com> Date: Fri, 3 Jul 2026 14:42:33 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Thunderbird Daily Subject: Re: [RFC] mpam,x86,fs/resctrl: Generic schema description Proof of Concept To: Fenghua Yu , Reinette Chatre , Tony Luck , James Morse , Dave Martin , Babu Moger , Drew Fustini , Chen Yu Cc: Borislav Petkov , Thomas Gleixner , Dave Hansen , Peter Newman , "x86@kernel.org" , "linux-kernel@vger.kernel.org" References: <5ee87762-1898-4b62-94da-85b3e9917ecc@intel.com> <62701203-c4a3-4ec2-a9af-602e1fc15863@nvidia.com> <76af8d95-8150-4118-8bfd-2347a64f6155@arm.com> <42a1b00b-c8a0-44fd-b454-df7f9bf25338@nvidia.com> Content-Language: en-US From: Ben Horgan In-Reply-To: <42a1b00b-c8a0-44fd-b454-df7f9bf25338@nvidia.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Fenghua, On 7/2/26 16:16, Fenghua Yu wrote: > Hi, Ben, > > On 7/2/26 06:37, Ben Horgan wrote: >> Hi Fenghua, >> >> On 6/25/26 02:26, Fenghua Yu wrote: >>> Hi, Reinette, >>> >>> On 6/24/26 15:22, Reinette Chatre wrote: >>>> Hi Fenghua, >>>> >>>> On 6/24/26 12:08 PM, Fenghua Yu wrote: >>>>> Hi, Reinette, Ben, Shaopen, et al, >>>>> >>>>> On 5/29/26 11:06, Reinette Chatre wrote: >>>>> >>>>> As Shaopen and Ben mentioned earlier, we are working on two MPAM >>>>> features that may need to change schemata interface. The CPU-less >>>>> feature was discussed on LPC (although the interfaces will be >>>>> slightly different from the LPC). >>>> >>>> I know. Here is where I tried to engage with you on needed interfaces >>>> after LPC: >>>> https://lore.kernel.org/lkml/fb1e2686-237b-4536- >>>> acd6-15159abafcba@intel.com/ >>> >>> MPAM ACPI defines MSC (Memory System Control) is defined in one of two >>> ways (not both) on one platform: >>> 1. L3 and memory together on each processor MSC >>> 2. L3 in processor MSC and memory control/monitoring in different memory >>> MSCs. >> >> On one platform, if there are MSC with memory bandwidth monitors or >> controls in both your slc and at the memory controllers then the MPAM >> ACPI tables would describe those at the memory as being at the memory >> and those at the cache. >> >> This could lead to having memory bandwidth controls/monitors at both L3 >> and memory scope. >> > > The locator type in MSC for this L3 is still 1, right? > > So the control and monitor example could be: > > MSC0: type 1 L3 with cache id 0 on socket 0 > MSC1: type 1 L3 with cache id 1 on socket 1 > MSC2: type 2 memory with numa node 1 on socket 0 > MSC3: type 2 memory with numa node 1 on socket 1 > > The schemata file could be: >      L3: 0=fff;1=fff <-- cache control on cache id >      MB: 0=fff;1=fff <-- memory bandwidth control on cache id. legacy. > MB_NODE: 1=100;2=100 <-- memory bandwidth conttrol on node id. CPU-less > > Cache and memory bandwidth monitoring: > On cache id 0, both llc_occupancy and total_bytes are monitored: > mon_data/mon_L3_00/mbm_llc_occupancy > mon_data/mon_L3_00/mbm_total_byptes > On cache id 1, both llc_occupancy and total_bytes are monitored:: > mon_data/mon_L3_01/mbm_llc_occupancy > mon_data/mon_L3_01/mbm_total_bytes > > On NUMA node 1, only total_bytes is monitored: > mon_data/mon_NODE_01/mbm_total_bytes > On NUMA node 2, only total bytes is monitored: > mon_data/mon_NODE_02/mbm_total_bytes Yes, this all looks sensible. > >>> On type 1 platform, schemata is legacy: >>> MB:1=100;2=100  <-- cache id 1 and 2 as domain id >>> >>> On type 2 platform, I will not reuse "MB:" name. Instead, define new >>> resource name "MBN:" for numa node and schemata is: >>> MBN:0=100;1=100;2=100;10=100;18=100;26=100 <-- numa id 0, 1, 2, 10, 18, >>>                             26 as domain id >>> On type 2 platform, there won't be "MB:" line. Numa 0 and 1 >>> are for mbm allocation on socket 0 and 1. 2,10, 18 and 26 are for GPU >>> memory nodes allocation. >>> >>> BTW, Slow MBA (SMBA) is different from MBA Numa (MBN). SMBA still relies >>> on L3 and the domain id in SMBA is still cache id. MBN depends on each >>> memory controlor with numa id as domain id for both CPU and CPU-less >>> memory nodes. >>> >>> On type 1 platform, there is only MB: >>> >>> info >>> └── MB >>>      └── resource_schemata >>>          ├── MB >>>          │   ├── max >>>          │   ├── min >>>          │   ├── resolution >>>          │   ├── scale >>>          │   ├── scope <== contains "L3" >>>          │   ├── tolerance >>>          │   ├── type >>>          │   └── unit >>> >>> On type 2 platform, there is only MBN: >>> info >>> └── MBN >>>      └── resource_schemata >>>          ├── MBN >>>          │   ├── max >>>          │   ├── min >>>          │   ├── resolution >>>          │   ├── scale >>>          │   ├── scope <== contains "NUMA" >>>          │   ├── tolerance >>>          │   ├── type >>>          │   └── unit >>> >>> This is different from the "scope" hierarchy discussed in the link. "MB" >>> and "MBN" won't exist on the same platform. >>> >>> I find it's hard (and not useful) to split "MB" for memory with CPU and >>> "MBN" for CPU-less memory node. It's easier to have either "MB" for >>> legacy memory with CPU or "MBN" for CPU-less memory. >> >> yes, I don't think CPU-less memory needs special casing in the interface >> once there is support for NUMA scope. >> >>> >>> Any thoughts? Does this update make sense? >> >> I think a _NODE postfix for controls with NUMA scope makes sense. I >> brought up naming of controls when they are the same but have different >> scope earlier in the thread and Reinette pointed me at this earlier >> discussion. > > Is _NODE postfix sufficient for future? > > e.g. SMMU locator id is IORT table node id. AFAICT, the node id is not a > numa node. If that's the case, _NODE postfix may cause confusion here. > > Is explict "_NUMA" postfix clearer? How is the SMMU locator id displayed to the user? For the NUMA node id we already use the name node in sysfs, /sys/devices/system/node/node Thanks, Ben > > [SNIP] > > Thanks. > > -Fenghua