From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.17]) (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 4F35B35DA6A for ; Tue, 14 Jul 2026 08:51:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=192.198.163.17 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784019094; cv=fail; b=PipPeO1STX8bYSlxfi+utLQoroDNaoNpPD4Nb7tFIiD1k6eAOb512tH5UfbP6APsVWWR20AdHL5whOybVuJiWw/lUpdcb6gRRrphNfUds+Bek0UzhkREMOkPBJJBZjq5wOnoEQ0NPWwn6kxqLXl9bjvsPmZKZflWR03nIx7haM0= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784019094; c=relaxed/simple; bh=nMH9LMM5wJlRnY01sc81iXgrbrvIEhelhtBqd0z7JVY=; h=Message-ID:Date:Subject:To:CC:References:From:In-Reply-To: Content-Type:MIME-Version; b=BeahJktT8Gn9yxbhqv28/ncb0BsxRyk/lsC00DEBLwkVr65ut0AHv2kedHhPBZgctB3ONj1R0aBJFYD79fwsvQEkBp1+4wSVrbCXin4D0ByZ0PflttB8NdvzCtI3v1lsI0GRYOqyQLVv/R9i2EClDqAGIzXjALxixIWvQWSqT5Y= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=OUe6J57h; arc=fail smtp.client-ip=192.198.163.17 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="OUe6J57h" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1784019092; x=1815555092; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=nMH9LMM5wJlRnY01sc81iXgrbrvIEhelhtBqd0z7JVY=; b=OUe6J57hrZKveWdgbd+gtcZFJM7zCdZ3XoffvoqsAZU5NEGQ+Yt9wEy+ 8xv0eXzZpQnu3vW++vW09QWEyUbwRwcijy2GdnmL9+/rdbru+s1nV6hqm xVp2xnMZZkDWs2yDQ10YufqUYJiiuJcfoRq+fxXmqnav2aMpO86fgLEx4 at3/k89s0kDLjHQVXjlumy7fW8kb/omHRkYyN8wC4PzTDpj5ir3Zp174i 0bk3HO2U3we0x3Q+ZNSM9SLDjT3XOsVYUsMHj/3p2NEJjo0pJaqctZYmN GIN1JGWRTn00p5YtnwQQu3ZRN6Vyw7OT27i2/V71xJ0sSj5iBL3JfkPRs g==; X-CSE-ConnectionGUID: E3EqnhD4SWSvOU/NhxkBXA== X-CSE-MsgGUID: 9xdTYNm0QdSSKuqLwiXEnQ== X-IronPort-AV: E=McAfee;i="6800,10657,11846"; a="84516064" X-IronPort-AV: E=Sophos;i="6.25,163,1779174000"; d="scan'208";a="84516064" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by fmvoesa111.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Jul 2026 01:51:31 -0700 X-CSE-ConnectionGUID: 0ZvdWP1DQOS+L3tk4JXJiw== X-CSE-MsgGUID: MNh7CtbkQRyHXVNq1y1MEA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,163,1779174000"; d="scan'208";a="259647163" Received: from orsmsx903.amr.corp.intel.com ([10.22.229.25]) by orviesa004.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Jul 2026 01:51:31 -0700 Received: from ORSMSX903.amr.corp.intel.com (10.22.229.25) by ORSMSX903.amr.corp.intel.com (10.22.229.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.43; Tue, 14 Jul 2026 01:51:31 -0700 Received: from ORSEDG902.ED.cps.intel.com (10.7.248.12) by ORSMSX903.amr.corp.intel.com (10.22.229.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.43 via Frontend Transport; Tue, 14 Jul 2026 01:51:31 -0700 Received: from MW6PR02CU001.outbound.protection.outlook.com (52.101.48.68) by edgegateway.intel.com (134.134.137.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.43; Tue, 14 Jul 2026 01:51:30 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=YZea913sh/OzkZe0XgcFd2rG9CREQoJgL4arAzkrusLz/Txz2b7jjRNILGSrcM3ugFjcFwWHWp9ME4+R2o6XkkZDaP6hYdiHKHJB9s+aX8nOO54g3gFURhGC6ZJH5x8YIubUZfn8FRxPTulPMdpOKx9/c7SeZUsud7Ee2tNt+tvEYhXRlNBG0iA6rSxb82dYNMi/ohiXrLVFQco3sbtFCB+FutqLUYEV/Te5wGDKOJfTBdEj6mEMdHHFsocAuwvCbglP03kaOtxksz27fR6/thvK68m7RgeNHgwcQjS8FRj/9eqloIC6l/DAUg+BB2ElOsg+QkXpXN9h+wZvGtqt0w== 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=6RqSbHxFNzfekKtqpH7hIzL7W7hq7Ns/2rAA45IiIHg=; b=PAVc+o6pi6p3GzRxuYGzG2Ve8gTlE93hrg/GcUwByXQiPT4p2mZKL/VkC7kCkl5oCXoQOWKs9Rfq9WK/bWTclGJS4loLpH3BgZrcoNANL6nUSGI0ie/xIkO0GeuxHPIkQi2DwZ+ymvSoMENltdPXIpz6FgI16FReYoSyB7pXCD2iUYgRvF8cNCYCJHyEgP/jT5rMQPXxpHRmEUp6eYWi427z9HeFUkS/ECt9y4j13SBLjOaQURrwdl5surIJyVw7o9fBdx/sKsdVmHxsrEvt4BJ6YKvj4XH0EzrLLnWtOP1TA2Wght3T+DK8iu4tvjcN28jRRT/KjuacflKf6CgXDQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; Received: from DM4PR11MB6020.namprd11.prod.outlook.com (2603:10b6:8:61::19) by SA1PR11MB6664.namprd11.prod.outlook.com (2603:10b6:806:258::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.202.18; Tue, 14 Jul 2026 08:51:25 +0000 Received: from DM4PR11MB6020.namprd11.prod.outlook.com ([fe80::3058:1480:e4ac:5765]) by DM4PR11MB6020.namprd11.prod.outlook.com ([fe80::3058:1480:e4ac:5765%4]) with mapi id 15.21.0202.018; Tue, 14 Jul 2026 08:51:25 +0000 Message-ID: <6afb8033-7e19-402b-9349-34cbf66897ef@intel.com> Date: Tue, 14 Jul 2026 16:51:14 +0800 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 04/10] x86/resctrl: Attach ACPI ERDT information to L3 mon domain on CPU online To: Reinette Chatre CC: , , , , , , , , , , , Hongyu Ning , References: <950d1001ae525871a20599e8702f6de4dbc9d482.1782866200.git.yu.c.chen@intel.com> Content-Language: en-US From: "Chen, Yu C" In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: TP0P295CA0016.TWNP295.PROD.OUTLOOK.COM (2603:1096:910:5::20) To DM4PR11MB6020.namprd11.prod.outlook.com (2603:10b6:8:61::19) 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: DM4PR11MB6020:EE_|SA1PR11MB6664:EE_ X-MS-Office365-Filtering-Correlation-Id: 4f83cc91-61d9-4465-b20f-08dee18515e0 X-LD-Processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|1800799024|366016|376014|7416014|6133799003|56012099006|11063799006|4143699003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: B2QCp8zrQuWamyiKnqpg1A3cgjw5HyllLLMJGIcrmunJ9Kiw5N27G5KbiF3RkvDgnu9Igl7TQ9sGNXRe2tOg4bMH4nI6rdjqt80ga+KPxdfrNcdogqDQcm0q8OFIlFmAFrJ+AmtV8+8ZGCdXXVMPiYhQqGt4LidfXbS5cd3J+C3Sk/lrAWazeGpT48WN3X1dNDehJK30yUaVpg69N4qtKWylWnE0I/FbUDAElCQ4FItzIvKaSC/SqZVDlhM+DrGLQ7rplsDI8vpG5jC0d/YvYPN8D+nWwcFC9UzL4nBYy4yET1AJmC4MTN2Px0H5KucN2vmaS7KgWRvPLgY2lJos2RofKnL31Qqq00f9Y8vUmfnMaHCV0htY5I7TdI7oV+pxP0ZktOq3ZWL28+Bsil7NLkPOmK0I9jeTNURocCFCz4A3KxtaUgn5Lrrip9k9i0yrv5N6MUUSNgrUK0KyfgDt+uZL+4ErIayPbNUtHv0NTtwSLN45oPVSdQXflN5m7N3DaamBftjGq/dgBgQ6Xcxr4NU7HmNkHG7rfTskz40BZnEEIDYR6bf6o87IYs4ZMvTi/LPO/KsOfCDzCgbn6FTlGEmrL25aDupGD/KSDZZoDvcuZQtDnw8mpglxhMIXm/bUupwA7lZBmtCiec9/UdQphtH1mBZFb/GEZUO+PpWJ02A= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR11MB6020.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(1800799024)(366016)(376014)(7416014)(6133799003)(56012099006)(11063799006)(4143699003)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?MHNQL2FkQUsrazhud1JROE1Cc3lERyt1NVVwSlVDQmtPYXRGUWdvb1Fjem1s?= =?utf-8?B?YlhGODQzT0dnbnZBbUlxU1RsOWFJamVjQnJGSGl0ckdTSGV6NW1UQzJsWm4x?= =?utf-8?B?NjFrazhvRGFtckxtcGRtR2hncWh1ME5BNlN2VGQwNHhvZzlZR3BRWEQvMjg5?= =?utf-8?B?b1BHOFZIUVFRQStrSW43Vm9oelNOemtneHNTck5KbUlNeWtiZXJPMXBoZ1dR?= =?utf-8?B?a1hIM2VoNXk1VTBNNnAzK0NYWW9HaytUN3dQd2JBc1QzTVVsNlI3dUhyV1FE?= =?utf-8?B?b3QxQkFpVWZBU2c3NlFYY2NSZDc3NStCaUlIVHpIYmVxdldnK1lwVjRIYVFO?= =?utf-8?B?SWR4NTRYQitsNFo2ZUo2Z3RaNjkrTU0xTkN5ZHZZK1o2NklTUHhCc2RXWllv?= =?utf-8?B?NDFmaFRiOXlhbFhlbkV3Syt0SnNnMmxCRTJzdDBUWXdQZWE2WjhjNS9GZjBr?= =?utf-8?B?enBRUkJwMXhMSW1IeUs5MGdiSHM0TisxTzk0UFErYkZsUitmVUJ5RVhyazVp?= =?utf-8?B?ZDQ1WmRSdkt6akJKQjdTbHJpdnRvRm4vRXFwTDdaR0poS1NhcjVrZng2Nk5s?= =?utf-8?B?NkxnUkdaOGdWeG5CZFR0YkdEY2RjdS9vb0RjY0psZlZaU0RzbVhrbkVZR1gx?= =?utf-8?B?TzJLTlVKaFQ0Z1ZNSmg2MEpPZFhIajZjYVU4TmZ1cHhFWlFySHg5ZUw3eWRs?= =?utf-8?B?NEpPSm4rSi8zNk0ydk1tSTNmZUtOblFwUE8yWmcydVlpQzgxaERpRmxFc0Nm?= =?utf-8?B?UGpXUEJjcXB3SUdzaHNEd2pFZjE4ZURKSnM3eE93UnFVZDVPSnpqME5pNEJp?= =?utf-8?B?TFJZd1o3OGJEUURySU0zQjMrbnhLTlJyNW5lMW1KTS84amZVR2Y3bzcrdlB4?= =?utf-8?B?TWdOVGlHQ096cmRSR0FzaytXdUFhNzVKVlA4K2IzeDNrNUVwa3VvVkRGSUNr?= =?utf-8?B?UkFzeHZCQXdvNE1Eb3pnTkQrM2ZRLzBvdU1Yb0hoalg5QjlLL05lczVEOSts?= =?utf-8?B?cktvWGI3bmdTeWJyeFhhUXltbEFVdi9WaTFzcG1WN1lDWjVKYy9nL1pSRnp3?= =?utf-8?B?TlY4Si9OM1JIS1RRQitWSGFzeUR4YURPTFhmVkZ2SlhTbDlGbnRXUzVTczlJ?= =?utf-8?B?V3NCZTJWdkZCNHY5M1BjUWx6aEJiK2RJWE82QWliS3o3dmt1dGlqaXVaUjJl?= =?utf-8?B?MG9LRkppelRRWE1tT3ltdG94STBjbTBJb0JuMG4xU3V4eVoybjRaQzNyUUpM?= =?utf-8?B?STdoYVV3VzNkbFdsNlViUFVXd0UzbXBES0lESG1TV211ZjB6OHU0R01WU2hH?= =?utf-8?B?TllSSmhMempVVEJVN2U5SzBOeWNsQU9IbDNwajBLR3FwallTOGtnUFRqYVJF?= =?utf-8?B?TEM5eCtKNWlQV052aVk5V3poOVBQY0JPdkRZSmpUbmJ4RDBjWWkrTnhTWEpw?= =?utf-8?B?L0ljZzIzQXNTellxWTFGWWxOVm5JUnBnWE5CSHJ2WE5PVnV3emhSajZnb2RH?= =?utf-8?B?NHllWXBSQ0cybU42N3V6dStpd3RMbzhDN2JSRkpBM0FranBjeGZhL2NBY2Ex?= =?utf-8?B?SnNsczQ5dUJ3MmdST0NYZlViOHViMU13MkZPSnZ2RTdsWHAzUXdQSGdLVHJN?= =?utf-8?B?Z2ZGYTVMZFArUlBKZTZZNVFoMXNxSEdrWmFuTUtjWHdWb3BBNGJYMXpNV1Fk?= =?utf-8?B?Yk5pbkR3a2E0UEMzZndXMXllUjJBZXp1QTFWT2xqaWk2MDFiWHFEb3J4RWQy?= =?utf-8?B?dWN2NDJpbGU3c0Zid0FUczdlQmFwR2czM1VxOUcxSVFKWFVnQlkzenNEZlFz?= =?utf-8?B?QkpqWnNERFI1Z29aVEQya1FKZkpKdkxQMFRVWGYwdXUxSDV4d1ZvRzdLeWVi?= =?utf-8?B?dm4zalpIUE1Zb0lwd0RVcUZ3VFdwRHpyMUMwUGlmYS9KbnBSOVNqcW52a0RT?= =?utf-8?B?ZE9TMHNQWHVYVzE2TkppbGhxRUFlaFczR280NU5URHplaFNjQzVzUGR3OGZh?= =?utf-8?B?QUNYd1c0RVpOWjkzaENFN0xtbFRRWFNOQnpBQVhkcFdPTWRIQkFna2ZMSnFa?= =?utf-8?B?NjluTXhhUm1EUDU5Z3lwUmd1bE9GcHFENSt6VUNnMkZZK1RuV1d0UTkvNmpG?= =?utf-8?B?OHUzSFZabnIwSWlaUyt6TWV6V2p3RW5lZGpWeXBGb0k3bkZENEluT2NWcU03?= =?utf-8?B?a0ljSWVTbzhJL2ZHMzdBalVRL2N3WUMrc2NxTEpTckF2c2VzV0FvQmM1ZTlP?= =?utf-8?B?ZW12blpRdTJMT0VFMzlHR0JBaHRTRzVJNURBa0x6VnBEUkdFUGxGZEM1Nm1r?= =?utf-8?B?dzVlaHRaSDIrQzJ6TE9vSDd0RHZoczQzQ2VjUGVUZml1NzJRSmRPQT09?= X-Exchange-RoutingPolicyChecked: JHXKx9jI1HOw4aFiyfvZcxLRqtwJW+7QqbXS9klGv779+LSlOv/JdhU3H7L6TvfCOilMCSjYpYymine8WOOF6ZU4dpiPqXI/rm/Vv2xhGO3mKXTtyd2WoEUmb43wg6jhglEv/90DWm2lOH+P8HA5CyDFTf+LD0TLspmrV/RzcspGwRo80JHmMAZyhdmyM4Ai+hdyR049JCTokL/lemF1eiEClx5nNgXiMzBcckLaDovwsd3/+xqj6cDSvwvK5Ai1S6p4FaYIIbVqkpqcUf6qjrW6b8WwsV1YskGL3kEglGkWBZt6pKHINvxq7yH5tWoBz8XUIBpXpScVw7+wJhjF0g== X-MS-Exchange-CrossTenant-Network-Message-Id: 4f83cc91-61d9-4465-b20f-08dee18515e0 X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB6020.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jul 2026 08:51:25.0282 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: xU5FDBG4THVlYC9uzfGNtDu/F9aK16i+VK55r79o2VvG76769hWOhwY3/kCEh8BOaHyQjtGe7p0//AMZcIotYA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR11MB6664 X-OriginatorOrg: intel.com Hi Reinette, On 7/11/2026 7:45 AM, Reinette Chatre wrote: > Hi Chenyu, > > On 7/1/26 6:45 AM, Chen Yu wrote: >> After the rdt_hw_l3_mon_domain has been created during CPU online, >> attach the pre-parsed ACPI ERDT table information to the >> rdt_hw_l3_mon_domain to facilitate monitor data read via the >> ERDT and its sub-tables information. > > Please follow tip guidance for changelog by starting with context before > jumping to what the patch does. > Okay, will update the changelog and all other patches accordingly. >> >> During attachment, a sanity check is triggered to verify whether the > > Please write in imperative tone. > OK. >> @@ -549,6 +549,19 @@ static void l3_mon_domain_setup(int cpu, int id, struct rdt_resource *r, struct >> d->ci_id = ci->id; >> cpumask_set_cpu(cpu, &d->hdr.cpu_mask); >> >> + /* >> + * Verify whether the CPU domain information matches the ACPI data. >> + * Skip adding the newly created domain to the list if there is a mismatch. >> + * ACPI information should be assigned to the domain prior to its insertion >> + * into the list, in case others might iterate the list in parallel. >> + */ >> + if (erdt_l3_mon_domain_setup(cpu, &d->hdr)) { >> + pr_warn("CPU%d has inconsistent domain information, do not add this new domain\n", cpu); > > erdt_l3_mon_domain_setup() already contains a pr_warn() when there is an error, is this > pr_warn() needed? > erdt_l3_mon_domain_setup() was used to detect mismatches, while l3_mon_domain_setup() would take corrective action upon a mismatch (CPU removal) - so they print slightly differently. After switching to your proposed approach below, all mismatch logging can be centralized within erdt.c >> + cpumask_clear_cpu(cpu, &d->hdr.cpu_mask); >> + l3_mon_domain_free(hw_dom); >> + return; >> + } > > Since the rdt_hw_l3_mon_domain was just allocated and the current CPU is the *only* > CPU assigned to it, erdt_l3_mon_domain_setup() should never fail? I do not think > any CPU checking is necessary here - when the flow reaches l3_mon_domain_setup() > it can just assign the ERDT domain directly, no? > You are right; this cpumask check is unnecessary for this newly created rdt_hw_l3_mon_domain case. erdt_l3_mon_domain_setup() was originally implemented to handle both the cpumask validation and ERDT domain assignment, and it was intended for use in both the !hdr and hdr paths. As a result, the !hdr path (for newly allocated rdt_hw_l3_mon_domain) carries unnecessary logic for cpumask mismatch detection. > >> + >> arch_mon_domain_online(r, d); >> >> if (l3_mon_domain_mbm_alloc(r->mon.num_rmid, hw_dom)) { >> @@ -591,6 +604,10 @@ static void domain_add_cpu_mon(int cpu, struct rdt_resource *r) >> resctrl_arch_mbm_cntr_assign_set_one(r); >> if (!hdr) >> l3_mon_domain_setup(cpu, id, r, add_pos); >> + else if (erdt_l3_mon_domain_setup(cpu, hdr)) { >> + pr_warn("CPU%d has inconsistent domain information, remove it from the domain\n", cpu); >> + cpumask_clear_cpu(cpu, &hdr->cpu_mask); > > I do not think it is necessary to add the CPU to hdr->cpu_mask for the ERDT test to > be performed (more below). It thus looks to me as though this ERDT domain assignment > should be split - the error check is only needed if there is a header and if that finds > a problem it can just bail early (before adding CPU to hdr->cpu_mask). Something like: > > hdr = resctrl_find_domain(&r->mon_domains, id, &add_pos); > if (hdr) { > if (/* This CPU's ERDT domain a NOT subset of hdr->cpu_mask */) > bail; > cpumask_set_cpu(cpu, &hdr->cpu_mask); > } > > switch (r->rid) { > case RDT_RESOURCE_L3: > ... > if (!hdr) > /* l3_mon_domain_setup() initializes hw_dom->d_info without CPU checking */ > l3_mon_domain_setup(cpu, id, r, add_pos); > > ... > } > Yes, this version is clearer. I will switch over to this approach. >> + } >> break; >> case RDT_RESOURCE_PERF_PKG: >> if (!hdr) >> diff --git a/arch/x86/kernel/cpu/resctrl/erdt.c b/arch/x86/kernel/cpu/resctrl/erdt.c >> index 6405df9be817..6c1df7e43eab 100644 >> --- a/arch/x86/kernel/cpu/resctrl/erdt.c >> +++ b/arch/x86/kernel/cpu/resctrl/erdt.c >> @@ -212,6 +212,55 @@ static __init bool parse_rmdd_entry(struct acpi_subtbl_hdr_16 *rmdd_hdr) >> return false; >> } >> >> +/* >> + * Associate ERDT table information with this domain. >> + */ >> +int erdt_l3_mon_domain_setup(int cpu, struct rdt_domain_hdr *hdr) >> +{ >> + struct rdt_hw_l3_mon_domain *hw_dom; >> + struct erdt_domain_info *d; >> + struct list_head *pos; >> + >> + if (!__erdt_enabled) >> + return 0; >> + >> + /* >> + * Find the erdt_domain_info that contains this CPU, > > Please use entire line length available. > OK, will do. >> + * compare erdt_domain_info's cpumask with the cpumask >> + * exposed by hw_dom (derived from CPUID leaf 4). >> + * If yes, assign the erdt_domain_info in the hw_dom, > > What does "If yes" refer to? > My intention was to state that the cpumask of hw_dom is a subset of the cpumask exposed by ERDT. Let me revise the expression. >> + * otherwise this CPU should be isolated from resctrl. >> + * For example, the hw_dom reports CPU{0,1} are in >> + * l3 domain0, CPU{2,3} belongs to domain1. Meanwhile > > Please use consistent terms (l3 -> L3, cpumask -> cpu_mask, etc.) > OK, will do. >> + * erdt_domain_info reports that CPU{0,2} are in domain0, >> + * CPU{1,3} are in domain1. So when it comes to CPU1, >> + * a mismatch is detected, we should remove CPU1 from >> + * resctrl. > > CPU1 and CPU2? > I think it should be CPU1 and CPU3 that will be removed from resctrl - because the first CPU of the hw_dom->cpumask will not find a mismatch per your description previously. >> + */ >> + list_for_each(pos, &domain_info_list) { >> + d = container_of(pos, struct erdt_domain_info, list); > > list_for_each_entry() > OK, will do. >> + >> + if (cpumask_test_cpu(cpu, d->cpu_mask)) { >> + if (!cpumask_subset(&hdr->cpu_mask, d->cpu_mask)) { > > Consider the above two tests, the first, cpumask_test_cpu() already checks that CPU in > parameter belongs to d->cpu_mask, it is thus not required for the same CPU to be > a member of hdr->cpu_mask in the cpumask_subset() that follows? The callers currently > add the CPU to hdr->cpu_mask before calling erdt_l3_mon_domain_setup() and then > remove the CPU on failure ... that thus looks unnecessary? Caller can just add the > CPU to hdr->cpu_mask on success? > Yes, let me replace this "set then clear on error" by "checking cpu sanity before setting it to hdr->cpu_mask" >> --- a/arch/x86/kernel/cpu/resctrl/internal.h >> +++ b/arch/x86/kernel/cpu/resctrl/internal.h >> @@ -92,14 +92,18 @@ struct rdt_hw_ctrl_domain { >> * @arch_mbm_states: Per-event pointer to the MBM event's saved state. >> * An MBM event's state is an array of struct arch_mbm_state >> * indexed by RMID on x86. >> + * @d_info: ERDT table information of this domain(read-only) > > read-only in comments can be made explicit with a const below? > Ok, will change it to const struct erdt_domain_info *d_info; as after hw_dom->d_info = d, the content of the pointed-to erdt_domain_info is never modified through d_info. thanks, Chenyu