From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from CY7PR03CU001.outbound.protection.outlook.com (mail-westcentralusazon11010027.outbound.protection.outlook.com [40.93.198.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C453427874F for ; Thu, 2 Jul 2026 15:16:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=40.93.198.27 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783005399; cv=fail; b=MgZLrZTJmcAwcuUg4GPr5aOjOdJPvGip1ThEshPb9o8WZ29MhRVqHJUM9fQZqmfDhub8BPwf7SEyePyPPPs2Nonj69Z/Xs+m/5OZ20yJKuc9h2HrauBIez4UEVpU5DsgpXBbuzJi3SAXVtL0hhMQmqUQvXJqmMr9lQDqRlFSP1s= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783005399; c=relaxed/simple; bh=C9grMqRgAkazZiU3q7LVuMpYQug8LMREHG2cW3nuJpA=; h=Message-ID:Date:Subject:To:Cc:References:From:In-Reply-To: Content-Type:MIME-Version; b=sJ3NHKWa0OEMC+9Cx03x9d1Lpo+EAzNUx63FhZjU9Iwht+3rf6phH708L+4S3YU+ew59uV9y+cMHo38adB/0o+h5BkBhL3BgIgrzjTxgGtwlIdyLiml++Qnx9l4n4TSsyuFRrVzHjqLNapJLIuFHwmSjDWvIWqbKegLcKchBqVA= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=nvidia.com; spf=fail smtp.mailfrom=nvidia.com; dkim=pass (2048-bit key) header.d=Nvidia.com header.i=@Nvidia.com header.b=aWYVoyKA; arc=fail smtp.client-ip=40.93.198.27 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=nvidia.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=nvidia.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=Nvidia.com header.i=@Nvidia.com header.b="aWYVoyKA" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=C8vOE08M7FLbhwC+Iq9kvG6uDXhjKXfZR8gDaOFnkHcDM7ZRrFCB6wOkiKfgHrWZ3XzN/CtvAoblFjGF4BPGr3bZFijGkmO0ZCDrLlXHEu1BIufmvROkAZQ2YDfvEXEV9z2hr45fORtjQPAco83a/LrV48hLSjfmm7ADkLag+ibLjVTACKtqkzJ/pvLPPfmR/qaOYx4ntNJqk89jegNqEzaX++fO7IsCD1eK5NhTPumEaBzR5uwo53C63RBDNsX3MPeWW3zkCbiydeyuQ/diJyjUx3QPUaHyjblsPX2cTXI0AahwDAP/SyPc5FTgDz+4XzJnxMXQc92a2OYnsFdiqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=+1WpwVIu6CV0tjYyUV+pR3c7vIgZ769ReyHgixEOf6c=; b=Qyf3XzHu5Y7iw4VHs3+w+O4z8GjSxCsT+GMNRvgRYdQ2x8ZNAUlHc3EP0DH8abkeFmRcqGQOIS3ntvtybWgJ7Aa4+qt5JZuXKLGK+KRDW4jHQrVzjLFxfM/aCKp2M8Rf7aAuqiJKDu0x7sJaQvKVkiBoobhLHARAVVFmrOZQnFmv5jNL9/Y9Yff308hkmC48E+153iwnt485uZmTvpzt8DyF+KMORU2/q30V0P3ta+3/wOg3+trmeRuaBcYxD+pEIYHtWNkdIlldJNXcNLxLQAJBUPNjVpwOLTj0kJCINIH0a+s/Zlcvaf7v9g9BttAaeYvtt1vsDOuBlnOGhip0lA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+1WpwVIu6CV0tjYyUV+pR3c7vIgZ769ReyHgixEOf6c=; b=aWYVoyKAUUwzq8mTMMBhCFk9efW75T81zDufVVK/Po3zJ8tbT9m05EePHC0kA3HWz2eg6ZFgPp0DGnQA6y9rGNfsQB8pG3satNvBIZAUFNss1imA+yHYS8ScqcrOylUpT3CEawiz5+rxJt8P5EwnqInD4ruJEe6gHGJspJIrQOVuN9mrkeENmr/sRvG7Kgms/dRhBW9Zff6nOEMmBu2/kfLwZB8Wn8n7/4vDqEkO6CqCwrTxvtpJ9Y8oBPTUSiCFz3u4Dym0csdTstSUjz2hv9UHxa9YEB8I3JAiusolqSIwzBoMJXkS2K57J+3GW4ro8k+RNb+isc0mtwwpajc/GQ== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nvidia.com; Received: from DM4PR12MB5230.namprd12.prod.outlook.com (2603:10b6:5:399::11) by SJ0PR12MB6880.namprd12.prod.outlook.com (2603:10b6:a03:485::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.181.10; Thu, 2 Jul 2026 15:16:30 +0000 Received: from DM4PR12MB5230.namprd12.prod.outlook.com ([fe80::6e87:1bde:1853:3b73]) by DM4PR12MB5230.namprd12.prod.outlook.com ([fe80::6e87:1bde:1853:3b73%4]) with mapi id 15.21.0181.009; Thu, 2 Jul 2026 15:16:30 +0000 Message-ID: <42a1b00b-c8a0-44fd-b454-df7f9bf25338@nvidia.com> Date: Thu, 2 Jul 2026 08:16:28 -0700 User-Agent: Mozilla Thunderbird Subject: Re: [RFC] mpam,x86,fs/resctrl: Generic schema description Proof of Concept To: Ben Horgan , 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> Content-Language: en-US From: Fenghua Yu In-Reply-To: <76af8d95-8150-4118-8bfd-2347a64f6155@arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: SJ0PR03CA0005.namprd03.prod.outlook.com (2603:10b6:a03:33a::10) To DM4PR12MB5230.namprd12.prod.outlook.com (2603:10b6:5:399::11) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DM4PR12MB5230:EE_|SJ0PR12MB6880:EE_ X-MS-Office365-Filtering-Correlation-Id: a2a6ed8e-2281-47a6-fd64-08ded84ce482 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|23010399003|7416014|376014|22082099003|18002099003|11063799006|4143699003|56012099006|3023799007; X-Microsoft-Antispam-Message-Info: eNSu8gXnPMqTv/gM9EEptAmBl2ioz9Dr3SkSO5TQCX1YnNlN+0JQ3nuunSiychCabwDwJW9gpDv9Bb8dWb+7EZCqu+2ChvWPyvk126HaGrJYk2AEk3lRjRFwPLSkaM00mi36VTMgcYrn4FOvgENmYb3Qz+Ii0jkp3pvzYqO4DKit1kTj2LhxE0UCvdVOcbc/L/zEc94R0kwr4Pzc6zpIuqKJfmBy58aTBWcE1XcIJxd4w174m0YX3KRyYOCXBAps/A0HN9TEAkiTR548MIgVX/zTLB7CVMck10YTy98oplE0AOzq2cfCmewDU5aV3KdshAtueAdAusHVsFnADfv+jX+X28wUfkjOfhGb9sfnE3Pj01wVxCz1lx8W4iXiowRjD2fFxzuYhBWWcWRSh6r53gIlBHHHtFL1ld6wkh+Syw3Nmip6zlBvoF2tP9J82PVOGs2Ct5JDjiMh4BLozyF2K/C2vvDKUQLahIHewdPS7KL2VmtSR7+blYizU6HA8k9E68COmftn4lINrvQ9M+KFVpcpjao2ClyMviWKkaiYsoLkbCRyBYsdGEIf1busfgaFJ8dgt8OJ92C9ZZeDLSrFDAGKoAyWs5MozvFdcDoSVkbv4rRTgdtQC3V2gensjyO+uLV5ZqiLdgfSXBouVfwR7cy2ZU7bJGqENkJB0memhGE= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR12MB5230.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(23010399003)(7416014)(376014)(22082099003)(18002099003)(11063799006)(4143699003)(56012099006)(3023799007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Q1k4VURITUYzT1kxYllSNjk4Y0RsZ3RBSitFcitwQVVxWDlQeFNkRW1ERmxG?= =?utf-8?B?TVh6M1g0Z0hWMTdJRG04MzBYdzdFQVB4RmZNUExNRnA3TGR5ZHhjU3JQTVV6?= =?utf-8?B?eUtPUUxVTU1VZFhRek1FNnQyaE85QzQ5aWJQL2xsSGFUOGp5d1ZWSkczK1kw?= =?utf-8?B?K3ZCNWdVNUVsVENuc0J2RHRFWjc2QWJnV1YzUVNRM1UrSEJsV3YvMlpIYzM1?= =?utf-8?B?R1F4dXRGZFUrSUVXQTQ2Ujd4cTJ5cnZRZHN6UUkrVGJ1Q1hlUEplN1dEc25a?= =?utf-8?B?NHhuZUI1UjVFZTkzampOWGFhZU4wYkRJNGUxMW9ENThiVXR3cnFLaUhYM1JO?= =?utf-8?B?dTJ6OWZXS05CTW5IWjZLVURYR3RSK2owSkdoMnNKR3hLUER2ZFRIb1VISHVP?= =?utf-8?B?d1RMZ2hXQ1hsSmJYRm9DOEZ0Zjg5ZXFudjFGT3MybS9YV1ppVlJxcjVIcHFx?= =?utf-8?B?Q0Rma1JpT1Z2R3dKRmNRRStUZ1lTdDFRcnFONWpyUWlTQjJMaWVtbzljcEJn?= =?utf-8?B?RjdSWXRoU0R2TDRkODJWSWhWQ3lPM2JXODZWT2svWTE0VXd5YUNqdm8wNlh0?= =?utf-8?B?c1doQVAzOHUzYm5KdGxlSnhLMEZqOUI4dWRKcDJhUFdKK3BrRlhxL3RsWEs4?= =?utf-8?B?SWtaSUt0VXVkTGZBYVBJa3E0dU41ZXdPN3hINGJpeDRJVFp5dXhkQTk5SCtu?= =?utf-8?B?anJOa2dnbVlxb09EVWRqdVJqalBmNzE3OTIxOFZ6ZHc0YURyZmluZlFtb0Iz?= =?utf-8?B?a2JIWlBKd3pkWHJ5ZXVSaFpMR0UyZklGaGVRcTh4b0QxaDZoT1lMSENVNXR5?= =?utf-8?B?eTk0S3MxQXpDdXFiZFF2K3hqS3RTaDdPSjJhK2U2NklPZEswNEhYZTJrTThR?= =?utf-8?B?MDR2amlabURSckRJYUxXNzkrc2t0Nnd4Vm84cGR4ZWxieHU5UmFLenYxdW52?= =?utf-8?B?aFVieVBnQjVjOWltT0w4SmFkNzY5SVJhTnl6Nkl4NE5mb05RQk9LbUxid0JX?= =?utf-8?B?dVdSSEREaG9KQ1Ezc2ZNMUtINWNZdEx4Y2dsUFlaTjdxRkJMaG93c2hZbzY5?= =?utf-8?B?U2wvdzdOMGhzaFFEOCtYQ3Y0RU5TN3ovYVB1RFd2ci9MbGVCL0Y4T0JwbUxq?= =?utf-8?B?TDgyRmhJN3F5eDduZDJyRWFsNTRIQU95WWthWjBRWjUzbmgvVkozVDlWQWRD?= =?utf-8?B?NUxpNldkNDFQWnJSWVpqV1FWNzBPUkxsSkhKM2NDT3JjdDRMWmd5Vmc5U2J2?= =?utf-8?B?OE9FaGN2WVJUNm9lT2luNEZXbmdhZFJsY3JxRGx2TkpwWUp6UEtZL2JLNUho?= =?utf-8?B?OHlzdjN0SS8wU3NwTS9NQXdlSkZPeHFhZmVrbHhLbXNFUkxFdVNoSUxYaGF5?= =?utf-8?B?SjJXaS95R0JIQnBmeWZSR2hSY09DcVo2azZNQU8rWFRHZklDRzZQdlVxZ0k1?= =?utf-8?B?S212dzRTbEhwZ1FGZXRVa0lrTTU2QlFlSE5ENGtKcjZJa3hkRFJBUFMydk9V?= =?utf-8?B?cytCRFhwWGJGM3FZT2VIZksxbFUrN1RtSjIreG5Sb0haL3ZFK1pMSDZVUS9D?= =?utf-8?B?c2tDY2JHNytTYTg0WFM1SVJBaWg5enRtOUkwc3VSNEZKKzQySk55V1Q2a2Fx?= =?utf-8?B?UG9iWGRuVU91a2VIMk9CVnllQnl4ZUJCZzg1aEhUbmRWdUIxNWs3WmppS1BZ?= =?utf-8?B?WkFuWVFqY0J2dmMxOGVtQ2JRekR3akhsRkZodUZyQ3VaVnNDbWNkOGxyNjZr?= =?utf-8?B?SDZTLzhONFdFMm1ZWjBlRUZESm5JRXN5dDNza2tmekdhdmJLdG1CSWdRWDIy?= =?utf-8?B?ZElQWS9uYzEyWG4zZGRUdXlGR1hsQ1VpL1NvYSt4TlV4ZmJTVE83L05VNXpp?= =?utf-8?B?bkMzbWZ1NkVZK0NLUFpXWXVocHpZeFVMNS9NNUpKN1VtQTJXTHVUelJOaHVD?= =?utf-8?B?bXNmMCsvYmdieDFRYjgrWUxBZWdWZmxhTzVwZFZaeG9DS3hCWGZQTEhCS2cy?= =?utf-8?B?NnhnT3ZEZlI1WG5QbUp4eHcwWllvak9leVdCUlNLNWo5NExydUttNjVxOGFF?= =?utf-8?B?QmVCSytDZXJIWHhnWjFTM05adjdTT1RGNjlMYmhERHhEN3hlN1FBc3dGMnJP?= =?utf-8?B?NVNIb0tIT2JjTEZ5MXMrOGRGanFhbzF1cnpjUWpDeG9xYUVvb01LK2hnTS9x?= =?utf-8?B?bTIzR0hEcXU1MU9yVk1OQjY0U2xHSUdDWGNISE1yUzlDNGZuamVBUU9POXNi?= =?utf-8?B?OHRHOEx2NERwaG1TZ05hMzREbkRMa2hOS25WR2I3TzVPZXcycmYwbHJITWNM?= =?utf-8?B?VXdiWnhJTFJzUGR1TWxkaGJEem9jUXFzaGNjS294QUJqK2V4L1ovZz09?= X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-Network-Message-Id: a2a6ed8e-2281-47a6-fd64-08ded84ce482 X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB5230.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Jul 2026 15:16:29.9129 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: qGF7lc9CBfOg+BaqiQOYOOuwig6a4jd/c/rsmUtV6hVy3qEiVPDmew9R+HZ9WuaVV2pKyBMrwOiHU9vPfJXEaQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR12MB6880 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 >> 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? [SNIP] Thanks. -Fenghua