From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.18]) (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 48E0C140E5F for ; Tue, 25 Aug 2026 05:54:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=198.175.65.18 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787637275; cv=fail; b=Ct8bWbWBqBoF4EjVJhg7fSp/b7nimxBpPWHvmTMPeth8iM+tmOO2oOO81J3fGQ7aqD9y3zt8n1cvveX6uHkU6VLzzUqeq70mQaXmehOoQTAERsUxl7cLMcjyERLC3DW+ifiPjC3MyFdDLaBxsV01xxEKooa74hdLU8lDCjaOwEM= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787637275; c=relaxed/simple; bh=nke11u3qsEmtWgdZJsXAE1VRkhrRYJUV1ddaIhybdxk=; h=Message-ID:Date:Subject:To:CC:References:From:In-Reply-To: Content-Type:MIME-Version; b=fxZWDoy2BdgMVNkzySK28PxUhIIYlrjfX4Qt9fs+JNk2JuWSEOrZ9cnHGmerpYPu6tupTH/x52YyKo8oHC00kWveyfzXYBjZhKG902KcOah3W0h8Awu28U8uNqju0jPgnrvyLZsKUwrqamKoM7ePsBFgLbT+3mcMup9NOyXLO9E= 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=IaI+8Ai9; arc=fail smtp.client-ip=198.175.65.18 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="IaI+8Ai9" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1787637273; x=1819173273; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=nke11u3qsEmtWgdZJsXAE1VRkhrRYJUV1ddaIhybdxk=; b=IaI+8Ai9c47gW208emLhbylEpi8l51s/JhYrytmuPl0kwDnkXsTfWszC PdF7jnwx2vkDJtGwSbwfE4BLP64xDYc0pZ/fMkA59eZGAR8PD8cmEOrFy ijMByHHYU8roPpZGQbufxppIzOd4opi0Sc0VUJD1vFrdjqrUp7ii67S62 x+PG4aSD1NvlD+qHQ7OcFh803/myycV/Gzc6bMma/sj/2o3y8CiyHUxRy laxJJQaw5ZEs1B1p544fgvkzIjNWA+YlYYXjqXaxt5meWjJoddy1qgYRX 5qmkRND4ZFyzytC9GE/VYKNY7tCKSBztIPFdst7ukQFd1TNAEP4CAjWK9 w==; X-CSE-ConnectionGUID: lCtqpzoLQVarIn/fRLIyzQ== X-CSE-MsgGUID: /TIJffMBR5euYzXXQ4hMvQ== X-IronPort-AV: E=McAfee;i="6800,10657,11885"; a="88153354" X-IronPort-AV: E=Sophos;i="6.25,242,1779174000"; d="scan'208";a="88153354" Received: from orviesa007.jf.intel.com ([10.64.159.147]) by orvoesa110.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Aug 2026 22:54:33 -0700 X-CSE-ConnectionGUID: W0BEskrxRzKB3vYW6Vi8cg== X-CSE-MsgGUID: WyPs7qDmTaWVYZPADqWn+w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,242,1779174000"; d="scan'208";a="267249079" Received: from fmsmsx903.amr.corp.intel.com ([10.18.126.92]) by orviesa007.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Aug 2026 22:54:33 -0700 Received: from FMSMSX901.amr.corp.intel.com (10.18.126.90) by fmsmsx903.amr.corp.intel.com (10.18.126.92) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Mon, 24 Aug 2026 22:54:32 -0700 Received: from fmsedg902.ED.cps.intel.com (10.1.192.144) by FMSMSX901.amr.corp.intel.com (10.18.126.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45 via Frontend Transport; Mon, 24 Aug 2026 22:54:32 -0700 Received: from SN4PR2101CU001.outbound.protection.outlook.com (40.93.195.4) by edgegateway.intel.com (192.55.55.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Mon, 24 Aug 2026 22:54:32 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ftTmmRWS8tVy3Q1onMdnB7SCcMXxIGAgvpYyWy7R8gSGOvsvfp1AxC67qi1rtZLUbUTDFl4qkSGx0sWgSGBc4WapAVWgw01RN5AiVs2+7L9rPPl270fhip3djGS6yym/zy08fHM9vS6kIasaIQWVxCD16GE6HZZKl8+Ts/iCcRmvGnhmbb9fDEsvnc2mQtuytbPePRGU4rw8UAWLhgwPbbkKF2GNwp6MFWAaDo186QjnWU3NOM8XM0RuCGbK67cVrft1Gw2ijMzM59D4wqt/m/YPgJ+soA641CUcksC1rpga//AUTqEHKvRLWsTzn76++WYb5ot9E+XmqVRW/mVLFw== 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=zlS9poLxoUIzxZyTlru9gCd9Aatxy6VC6GRIzxPK3YA=; b=iacy7+R+kz+2AO4kknubfZyZh+CJCgTFwnDiqQaUxbs/a5iNAzpovP0e9AGamfoFuqONHK3dlmpGaR+6a25IlCjQPmAakvX9H10XhNXuRuondwyVCc0GexhEXUvFmRKD+LuAhuiu4iTfEtckSBMtEMqsx94+HwaOSxq+k1TIQEwo9ar07OZM4VFCz4qmbz4sNhyl0xFQlAOn8+hgKYjywstDQUR1aGqM55jAD5IPtC0UgvgoCYqqyZv0b7xchtBqBpGxulj7b22WbdJNUO1Tyi6xHH66nEoasNv3MOi6hPL0hZu4nR89G9EiNaVxe+5IbeKqeXmqSKra2EcxYfkQYQ== 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 PH9PR11MB924967.namprd11.prod.outlook.com (2603:10b6:510:3e8::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.339.12; Tue, 25 Aug 2026 05:54:29 +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.0360.005; Tue, 25 Aug 2026 05:54:29 +0000 Message-ID: Date: Tue, 25 Aug 2026 13:54:19 +0800 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 4/9] x86/resctrl: Attach ACPI ERDT information to L3 mon domain on CPU online To: Reinette Chatre CC: , , , , , , , , , , References: <86349d88-2ddf-4849-bbd8-1c7371a73f09@intel.com> Content-Language: en-US From: "Chen, Yu C" In-Reply-To: <86349d88-2ddf-4849-bbd8-1c7371a73f09@intel.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: SI2PR02CA0008.apcprd02.prod.outlook.com (2603:1096:4:194::12) 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_|PH9PR11MB924967:EE_ X-MS-Office365-Filtering-Correlation-Id: 077b7d27-b293-4e0b-1027-08df026d5398 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|7416014|23010399003|18002099003|22082099003|56012099006|11063799006|6133799003|4143699003|10067099003; X-Microsoft-Antispam-Message-Info: T/3gbNk1tAE0ttBIQvLaV5SxQrhVdES6K7tsMaN4DOK+BWOKSEEq2QIELs9Nf9jHsbBpX/AtBU2PcVEgkNYtz5Zt/va4W1r8G09q+OnHNyLATLNMTI8TrCf3yk+j1Er9DuPz1TSkfwqrpgxMIlLtq4op8sR0uxmegeKTZ1iy35HdtULSQajn8eeEySxx8TbcXzY4Ke05q9JJxi8BDUVtsLf3NfxKeAT8hym7SDVR5Q2vMoTxo5qsYIaGTpMyqw2RLi6rMubyOAfs8C4CsWDwkF3RAKo4dQQC8C7T7bWFQr2DgvDZZkRCo7Xxqgy1k/LEXA3sa7f2K7OXQNk11Fd8YWXnQchrCIJoTUSl42a64mrhI1fcyW86/l9wsACKtmdmGGreuBprByAtNawxvXzbGgeinibne3wiRHqVnJySM9Q+dJHzbiZDpqbK90byab7tyvDnjFv9PDv8m4IM+9De2jdJm+4Ri8CG9EyBR+kdYzpUYwFnPemh+mFEsx8nKo2z3uewmlkuMSUEX7sYA1ZP4szDpf3x+uwgjiiQC3JUBwKTbnthQFV0w4xNOgPpMb7AvxBRQcIKQnZppTorsP3KSB++sU+mP9kEDSj4C2d0ZDyO759u4p5mxasxuXV4Y4MF1afHqqRdZT0WHVJ/DgVl080yg9ULf3dm4l6Q4JEPcMA= 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)(366016)(1800799024)(376014)(7416014)(23010399003)(18002099003)(22082099003)(56012099006)(11063799006)(6133799003)(4143699003)(10067099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?N1Y0MnlnWmRvTUtpTGE2c1llRXZoemI1Nm1WeDBtOUNLVzFJMVd4dEFXMy9G?= =?utf-8?B?ajRmQnNPckdVK21tMVhDNEx5TTBFL0orM09GSXBwSnhJaGxab1VManF0ZmVR?= =?utf-8?B?c1BVOWJNRUJ6c055Mzh1bXhtWG9jOTYrQjd1MG9FZ0tDc3ZsL1g5cEN0L2Vt?= =?utf-8?B?VXNjeEdhZDAxTW90VW82LzJTUVVFMXdGc2MxZVgzcjNlczdVaDdHNnphdUxu?= =?utf-8?B?MHRIRGExMnhuWGhPblJuZ0dnVWpFeFBwNm9HMVRQNEtNNk1lbFNWakQyWjJE?= =?utf-8?B?UW94ZG92QjFGYjJRc08zUjJ3a01RbnZrRkliL0tLT2Y3UzVzR1FyaXdqNGRX?= =?utf-8?B?blozSjFaUlB1ZmpCbHBIK1JqOExuSytsS1lEUloyUHc3alluZDVoTUVLWGFS?= =?utf-8?B?YkVvOUxkZVJzMVptS3cyZFhkNjBOSFYybE9lM3ZGUGNoeStGSThTTGp6SnVK?= =?utf-8?B?aDVmRVluREtyVFpqOHpmanVIU3VMdFVZeURlSW1JUkdZSGNuNEUzVHhjdjNv?= =?utf-8?B?WC9EUkovOGJFbVRkTXowQW5TNFRaTkZkbGJIRmJFYkszbjBpNjNGTXc4bDV0?= =?utf-8?B?QmhINkl1M0dWYkJ5YTJ1RFIzenFCQTh1RmFaQ2Z1ZnRCdXJGSzB5NTVOSy9X?= =?utf-8?B?OTVhTlF6a1JyYStQYUtlSDNJYkFtbjRNT1dVMDhjM0ZDd25EVWc1UDduczRt?= =?utf-8?B?OTRLeVoyZ0o5Q3QraGlNWjh4ZzB1SzVIell3ZWVkd29zU3RuVUFMZkhPSlc5?= =?utf-8?B?STAzN29sd3F0WCtHQXlZZkN2c1E2NG40bk11engvU2JabEtnRGlpM0ZqdEx2?= =?utf-8?B?RWhqSGczK1h0Rm1oQytMRjZFQ0dpZkdsb2Z4LzlhR1JRbjhkQkNFNUw0SlY0?= =?utf-8?B?dHVaT2tIeGJCMzhITm9QYTJnOWx5V2dzaS96eEY1SHpGUHg1TjV5RGhjSW9l?= =?utf-8?B?UmEwRW0ybmdLV1Y3VjZWd2Y1SE56RkpQc0pxTDV4Yko4c1RuNUgrT1J1d0l1?= =?utf-8?B?QitybExZakhVWjhnOFBLSHJUL2FRekNwVlFaa1ZqOGI3M0cxdUdQQ0NLd3F0?= =?utf-8?B?UkpVdnRNdGxsRm1UZlM1SmYvdFlMclZ1c2creXR2elFGR0MwQTl2a1dtL1hT?= =?utf-8?B?ajdCTk5aK3RLNExWYzFicVoyM0ZvQllXcGwxRU5pVlpOcDdZN3lIS0RIN3dK?= =?utf-8?B?dG9QS0V5UEtNYk5ubXBENFM0QURTWkJTZUVQcDFtR3g1NlNkKzc0RGpJRjVP?= =?utf-8?B?TlRZVUxWRGhvN1FvNkxBaEZ6M3lhQjNINUsvTVJadnVScjBydHl0TU9MREEw?= =?utf-8?B?aTA4UVNzU2xYTytmWHZoU3hwd1RlOUZxam1sM0Y3ZStWaFRETmMwK3VEbE4w?= =?utf-8?B?cVBjaWFCS20rYTRoM3I3SWRhVmNuakhMTnJSK2JhVDdIVy9kczBORW16dUNS?= =?utf-8?B?eVh0TlNDZC9JbFNXU1l6Um5razVQazIxWHRBUUJ0YzE1U1ZzR3R4TVNiV3Vy?= =?utf-8?B?NUhyRi9YaWtnUmR4VU8rbUFqN2g4b0tzN0dCTCtXWWo2Tkc2RWF6UElwRFUx?= =?utf-8?B?UjhnelNqYitpazVka1kwbDJQbWJZdVZtU0prenUveDlHeEQ1YVNYUzU0SEtx?= =?utf-8?B?Q1JCVUt3T21OdUM5TXNzNjZHR2ZFdk9WZGp4SnBDSllGUFRCaE1nZ0VlNVcz?= =?utf-8?B?ZGFrOVF1RDdZUHBWR0pzZEIwSXdDZ0I0N1l0amVSVVpqTjhkTERxeU04V1BB?= =?utf-8?B?K0s4SWUrWkxKcXlwNllaM3pxSHZkTzJwWUFhWVRkWllrQ0dQQjF3WlhQbDBV?= =?utf-8?B?YSs3TW4vdFBNNGpsUUNkTUdDTHFiNVExOThTMS8zNDVMOVViMFRoaVBBMUNG?= =?utf-8?B?UkM2R3ZPNVFRQXZ0NFNjVWk1ajhtbjhxaWFRT0JuenBxc3B4b1A5NjA5M1V4?= =?utf-8?B?bkg0c2VGOTRWMEdvbmh1Z21SbzV4L2RLYkZVOGx0NG5tRUxSLzVOUjV1OWRr?= =?utf-8?B?R2lxSUhiSjdPQlpNWW9WMXd6Nkd3eXFCa2cxYmNBTjB0WUU3bUluTTd5UHZE?= =?utf-8?B?b0NzV2J3UVpkR05zSzREZ1pQQkVtdFNnVnQ4S3NveXR4dEJGcFhkL2J2UC9t?= =?utf-8?B?bTZrbkZJSzU1d2RGUVJhZ1NmTGRlQ1BKWVlIUUhmNENrTUNVL1d3UEE5a3hM?= =?utf-8?B?QmltOFBLTlNTQTlTbDNpUk5lV3MwMkJjbmR0OWxvSFZ0bkFSR1IxdDZJRTFF?= =?utf-8?B?Y1NFaCtmQnhUSWtYb2VtVDF3ZE9veWEyVUFZOXVkdHdPZEdrcGZRZ3FwMWFW?= =?utf-8?B?TE5lQUdqN1VrWURpa1QxZ0FVdk5YOWxpaUhZTG5LV0hMOUwrWXF3UT09?= X-Exchange-RoutingPolicyChecked: At3+qhiI50vd/fpdghDlqy3YxiiFnxP9+ef3S8CIgNnLO/KQt7wLczCuo5Of5mjgoDmK53VPFDu7ExflZ64W50axPvgC48FeKqeNRy0pOFpRp3mQA9G3Oi8TslzGHK9WAYr0PS0NQ1M9u09+4yBqzyMLpPy14AHwTfPclj0bzAS/4L8voGsh66jF4b8aItCxgTAzQfAOwai3hmhhD9I+0HdODwqRfpTbzQ0kULXeZj+PcT5EUQZRhtoRzcjQ7nPUN6+tvYr2kO4vJ2r4GuKMKbABvh8ST+BFhRNEbsMOSET5Q72w360auNPtVXqmJpH0iQdGBj9UvhmWpuRifASDog== X-MS-Exchange-CrossTenant-Network-Message-Id: 077b7d27-b293-4e0b-1027-08df026d5398 X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB6020.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Aug 2026 05:54:28.9987 (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: 5FwFlqnUwWBqpvQJx1WGT2u1NSH5uOlAJ8w3WleW9IDnNk8BVLTIsgRONCsEEUKtxDHondC8cnXAbhcQlKO7iw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH9PR11MB924967 X-OriginatorOrg: intel.com Hi Reinette, On 8/20/2026 7:04 AM, Reinette Chatre wrote: > Hi Chenyu, > > On 7/25/26 2:23 AM, Chen Yu wrote: >> Reading LLC occupancy counters via MMIO requires the per-domain ERDT >> information, parsed earlier from the ACPI ERDT table, to be reachable > > Please avoid using terms about a patch's position in a series. You can > just drop "earlier". > Got it, will do. >> so that later code can read monitoring data via ERDT and its sub-tables. > > (similar comment as above) > "so that later code can read monitoring data via ERDT and its sub-tables" -> > "so that monitoring data can be read via ERDT and its sub-tables" > OK, will do. >> >> Suggested-by: Reinette Chatre >> Signed-off-by: Chen Yu >> Tested-by: Hongyu Ning >> --- > > ... > >> diff --git a/arch/x86/kernel/cpu/resctrl/core.c b/arch/x86/kernel/cpu/resctrl/core.c >> index 23925bcd71d7..c2568b29474e 100644 >> --- a/arch/x86/kernel/cpu/resctrl/core.c >> +++ b/arch/x86/kernel/cpu/resctrl/core.c >> @@ -580,6 +580,9 @@ static void domain_add_cpu_mon(int cpu, struct rdt_resource *r) >> return; >> } >> >> + if (!erdt_cpu_valid(cpu)) >> + return; >> + > > Including this check in domain_add_cpu_mon() means that it is repeated for every monitoring > resource. I think this check only needs to be done once? How about moving it to resctrl_arch_online_cpu() > where this check can be done before cycling through *any* (monitoring or control) resource? > Yes, moving it to resctrl_arch_online_cpu() is more reasonable, will adjust the code. > While domain_info_list is initialized early, this validity check makes concurrent changes to > it so locking is required. The current implementation already does this modification with > domain_list_lock held but it is not made explicit that this list is now under the protection > of this lock. Please add a snippet to the comment above the domain_list_lock to document that > it is now also used to protect domain_info_list. > OK, will add lockdep_assert_held(&domain_list_lock) in erdt_cpu_valid(). >> hdr = resctrl_find_domain(&r->mon_domains, id, &add_pos); >> if (hdr) >> cpumask_set_cpu(cpu, &hdr->cpu_mask); >> @@ -589,8 +592,14 @@ static void domain_add_cpu_mon(int cpu, struct rdt_resource *r) >> /* Update the mbm_assign_mode state for the CPU if supported */ >> if (r->mon.mbm_cntr_assignable) >> resctrl_arch_mbm_cntr_assign_set_one(r); >> - if (!hdr) >> + if (!hdr) { >> l3_mon_domain_setup(cpu, id, r, add_pos); >> + hdr = resctrl_find_domain(&r->mon_domains, id, NULL); >> + } >> + >> + if (hdr) >> + erdt_l3_mon_domain_setup(cpu, hdr); > > The additional search for "hdr" seems unnecessary. Could l3_mon_domain_setup() > just call erdt_l3_mon_domain_setup() directly? > OK, l3_mon_domain_setup() can leverage erdt_l3_mon_domain_setup() to attach the ERDT domain to the corresponding newly-created hw domain. And later when other CPUs of the same domain are onlined, they share the same hw_dom, so there is no need to re-attach the ERDT domain again. I'll adjust the code accordingly. >> +bool erdt_cpu_valid(int cpu) >> +{ >> + struct erdt_domain_info *d; >> + int dom_id; >> + >> + if (!erdt_enabled) >> + return true; >> + >> + dom_id = get_cpu_cacheinfo_id(cpu, RESCTRL_L3_CACHE); >> + if (dom_id < 0) >> + return true; > > Should this be "false"? Perhaps also with a warning similar to domain_add_cpu_mon()'s > warning when the domain ID cannot be determined? > Right, will fix this and also !erdt_enabled case, and add a warning here. >> + >> + /* >> + * Find the erdt_domain_info that contains this CPU, >> + * check if all CPUs in erdt_domain_info's cpumask >> + * have the same id(L3 id). >> + * >> + * For example, erdt_domain_info reports: >> + * domain0: CPU0, CPU2, domain1: CPU1, CPU3 >> + * rdt_domain_hdr reports: >> + * domain0: CPU0, CPU1, domain1: CPU2, CPU3 >> + * As a result, CPU1, CPU2 should not be covered by resctrl. >> + */ >> + list_for_each_entry(d, &domain_info_list, entry) { >> + > > (unnecessary empty line) > OK, will remove this. >> + if (cpumask_test_cpu(cpu, &d->cpu_mask)) { >> + if (d->dom_id == -1) { >> + d->dom_id = dom_id; >> + } else if (d->dom_id != dom_id) { >> + pr_warn(FW_BUG "CPU%d's id=%d not equal to CACD domain(%*pbl) id=%d, skip this CPU\n", >> + cpu, dom_id, cpumask_pr_args(&d->cpu_mask), d->dom_id); >> + >> + return false; >> + } >> + >> + return true; >> + } >> + } >> + >> + pr_warn(FW_BUG "Cannot find CACD domain for CPU%d\n", cpu); >> + return false; >> +} >> + >> +/* >> + * Associate ERDT table information with this domain. >> + */ >> +void 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; >> + >> + if (!erdt_enabled) >> + return; >> + >> + hw_dom = resctrl_to_arch_mon_dom(container_of(hdr, struct rdt_l3_mon_domain, hdr)); >> + >> + list_for_each_entry(d, &domain_info_list, entry) { >> + if (cpumask_test_cpu(cpu, &d->cpu_mask)) { > > Any motivation for why the cpumask is used as a test instead of the domain ID? > Let me switch to to compare the erdt_domain.id and the llc_id directly. >> + /* Assign the ERDT information to hw_dom */ >> + if (!hw_dom->d_info) >> + hw_dom->d_info = d; > > This should become obvious if this initialization is done from l3_mon_domain_setup() > where hw_mon would have been kzalloc'ed. This means that if hw_dom->d_info is > already initialized that there would be *two* ERDT domains that map to an existing > resctrl monitoring domain. That looks to be something to complain about? > Yes, this should be a firmware bug and let me add a warning here. thanks, Chenyu