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 A142D3B9950 for ; Tue, 26 May 2026 04:08:19 +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=1779768506; cv=fail; b=KU3qUYdhM6c5hrlnXTPhGvY5gGM0atijdQYfbszfOnOSYjbhuume/9VY4Mh7G1P0FrnemMHx3aYmzT5dxFSI3q0p0lxGGYxXcLcX/vrXG9n0Be+4TGVJE3jDayftwwvx3Dz79aU13TLOaZB1mUx5PPPBY38xtnQZV3ew6yeXQTs= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779768506; c=relaxed/simple; bh=1kFMe3YmsaqPrLLEVBhp6uZ5e12JmM0AUMQ92ELeOrI=; h=Message-ID:Date:Subject:To:CC:References:From:In-Reply-To: Content-Type:MIME-Version; b=tU2zqulFlKTzhn+r0eG4ms2CE+jmoYH31z/1Jk4Rz/c7b6AAz5BMv0UpU8DbNtd3pMaUmdl312pa+U3LDRZxpjDs1V84C2q0f8xyYpONTctcZOUJ03AHNT44FW8iFn3eD87/jpfZwtXllv8v6Hf1E9pRVHJiyHieCQU8bvB29vs= 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=BWNuhaRn; 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="BWNuhaRn" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1779768500; x=1811304500; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=1kFMe3YmsaqPrLLEVBhp6uZ5e12JmM0AUMQ92ELeOrI=; b=BWNuhaRnAzGVa8argP6VASbrsqgMrZJukmQ3mtligtiO1H+o5KgfbT95 Gyo0tuGWA9lxixlXZA0LtXycaExDWwlP17/GeP2L222hIDgxOlEcPWBpI 42h1du4ukzFIWIlCl4Yf0j6IQwTpLIR7HsHtgraLjHVa3UdP1gpDcgefs vZIG3+f4Qjlr/3FEUTsC+1jeZnkpJDec6JrTcicSRQ8YDEFPIw2VHqluG VHiU1NVm94Eq/czf/VelP3Gs8TCG8GLTWm5O8V8T2Z0TDBlDxpqpPrunz hAv8SkA8oU2s5ID/sObc9/tNh0hjM0UA7jxPGG7eyRt6lzd+vrGpggqxl w==; X-CSE-ConnectionGUID: L/VFoA+IQzCFgs57qLaqNQ== X-CSE-MsgGUID: srPFcV6nTjKS6XKQxjbjRw== X-IronPort-AV: E=McAfee;i="6800,10657,11797"; a="80631948" X-IronPort-AV: E=Sophos;i="6.24,169,1774335600"; d="scan'208";a="80631948" Received: from fmviesa003.fm.intel.com ([10.60.135.143]) by orvoesa110.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 May 2026 21:08:18 -0700 X-CSE-ConnectionGUID: lJOEFnVZTnG/Hl3X8WK1Ag== X-CSE-MsgGUID: 7Zb6FksMTTmp3YEKRwzcaQ== X-ExtLoop1: 1 Received: from orsmsx902.amr.corp.intel.com ([10.22.229.24]) by fmviesa003.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 May 2026 21:08:16 -0700 Received: from ORSMSX903.amr.corp.intel.com (10.22.229.25) by ORSMSX902.amr.corp.intel.com (10.22.229.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.37; Mon, 25 May 2026 21:08:16 -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.37 via Frontend Transport; Mon, 25 May 2026 21:08:16 -0700 Received: from CH5PR02CU005.outbound.protection.outlook.com (40.107.200.53) 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.37; Mon, 25 May 2026 21:08:15 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=WIxmVrtNzdWc0poz959rOUeF9RwOYIJIZGWKk4OtRkQu1uHsgHtJvkTTmqXvJQOn0lWHJq/gL4xwwQ7r3v/xVGqq3yqf358HMCDEvaFezHpZFk0UnvpTifNGmsLBbckLlJtflleVAFDyIvxkdVcNBPLFRsq1mYhRH3aZgumrpPetHv2jClxEBHyF7UI4wIEYwuX333qSxvJnf6UWLa/YkhkJ3lse9WY7Tgk/Ze4Iq2Kk/mUN5zLfqVQJHURy198vEPOMXqiSRC29KSJzxIb75MKl0XOU8jO5ra3ripvppwCHThDSuO8ZE/mlJ64cxh0VbmyaJJFbeIX2ubSP3BvTFA== 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=H1wa/vOc37DuGUGcMX8xXDFEBv19tC9EHFAG1im1KrM=; b=bhS9EvDodUa8LggKGmLSYc3XZst+TMHVn6RJhw1ij4gem3fTnt4z42YVBI1BbWnL5dAfkVOQ1MjDpySO8mFKKbAd1ZVzLpRIbEpO7V9HURA0bB8a4BkDuAi+utbF9Sb8Hm2Hi0tkIOCDHymNeZ+S0OpTNEWyqnP5+FahrR2O6/KRLjAW0wCjQtTwyGBqQKfW88dS8+F0qYRmNk1LhBh4xKXiC5IBEDegUdQ1RvQIDAhOGAW+Gy36uqf7OubQJev8tpVy0pIYYlPo9GHLVDawKdhNsxXFOLcR2H7kt5e12ExAt+wT/toXNnVASaBZxAmPhXdsoJMIOR421x2rVwahLQ== 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 SJ0PR11MB4831.namprd11.prod.outlook.com (2603:10b6:a03:2d2::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.48.20; Tue, 26 May 2026 04:08:13 +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.0048.019; Tue, 26 May 2026 04:08:13 +0000 Message-ID: Date: Tue, 26 May 2026 12:08:05 +0800 User-Agent: Mozilla Thunderbird Subject: Re: [BUG] sched/cache: "Make LLC id continuous" causes NULL cpumask dereference in build_sched_domains on POWER9 To: Srikar Dronamraju CC: Venkat Rao Bagalkote , Madhavan Srinivasan , Shrikanth Hegde , "Ritesh Harjani" , "Christophe Leroy (CS GROUP)" , LKML , linuxppc-dev , , , K Prateek Nayak , "Peter Zijlstra" References: <51154de7-3700-4cb4-82f2-1b3a8fa427f7@linux.ibm.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: TPYP295CA0060.TWNP295.PROD.OUTLOOK.COM (2603:1096:7d0:8::19) 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_|SJ0PR11MB4831:EE_ X-MS-Office365-Filtering-Correlation-Id: 0f1471d8-e491-4e13-1526-08debadc67e2 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|7416014|376014|366016|22082099003|18002099003|56012099003|11063799006|4143699003; X-Microsoft-Antispam-Message-Info: wDR3QuWrCMI/LXp4H3pU0Scc18DQiAEbBKSmT6qirzIv0MHrWzYMMbFwh6geoFYt0p0aj0bzEGHc4YNlxa1XtFDyW0DzdcGb/hHbEEalcLfJvyG2j2fZHrrp7ryFbMc5vX69Alch0pAaUk4dQOFcqWv7fF8F40EA7PSwoEb0F3nX59raa/vbiYOlry1TT93hL4eS3F6FtXoPe/CJCpZkdP348W8n+zrQ8fe2yeBd3Yl+2up02v5+IulRuxj1Pbo7mf0LhFWsjyt6ERlLZKGX6J9zBEz/YNDJCeM6sk/r5yjB41GRG5H5tb9PCvOZ8quzy8Jyqi0SEZJW9pO/6s3sakYlFjjzt/3Y2LAdKEIbvYaq9wrdYcqhWAgl11rpgvGddA0YXiKCXq43DCWcvNqLr6aKJaw1szyPO8AWUzzJLUS+ex5cwgEShAanUB9QC3WmFXdqLsajCw0RWAiPbBb0IodwHBzDoJjTYsrJluE4kvOAiGceQH35z8vIhpKt5ofX6tgROC4VMWeXnH0+fvDXiR+ThAxOex0PDUVlU24AkBuoPctBQu6QLD3X0mIuRACpPM6H9kRCsjZ37Ez4iDzqtq5vNxwmvoL8pjMXg+mlFwKtFFg0ydeY6NPht3RtW+3lScQ4L6REvgz9/UEg8gl3bB+R/j99rYKFY0th4vhbVs33uwzrxgd6LHz5jfux17MaqibRnGzKd1iTJ2GzWGdR8g== 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)(1800799024)(7416014)(376014)(366016)(22082099003)(18002099003)(56012099003)(11063799006)(4143699003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bjYxeWdlSWEyaGh5NWtDbDdRS0NXUndYamdtNjdzY1FULzFTWGpYdUV3cERs?= =?utf-8?B?ajdWWFVKTFUwL3dmeXlNN21RWHZ1cVFXRVFmengyWldiWkxqNk56c1Y1djk5?= =?utf-8?B?N0hnU29MQnkyRStpRXJPTWVZQmhJL0IrbmNwMDUrd2VXb3dZYThFS2NwQVpM?= =?utf-8?B?S2tiRGdYbUppMjh2dkFRTHFFQmUvZ0haL1JQcFFCV2ljbXlrenB0eHBCZlRt?= =?utf-8?B?UWpzbEloTldLemY1RUhDc2J5K3RUZ2NjMDZkVC9VdXMzVlpuQjhQd1JqZ3lJ?= =?utf-8?B?eDZDcWhHNUVQNTFjVEl4cld5b3NGV3cxSmFjTHNVekUzQ2dkQTF3a2lES244?= =?utf-8?B?dXVrRG5GdmhLSEc0Q0IrcEVMWUs0d1g3RlNrT1cvU0RjaVRqYmVGei9LYkhU?= =?utf-8?B?MFB6UkRQVVdpV0NqeUh5UnYwRnZHbm5JVHEvQVNUVVh0Z1ZReUpLRTBFQmtl?= =?utf-8?B?SjEwSHpSUVVzNVZ6R0ZDb0tndDZIeU84MXQ3T2lNVU4wL1BLMlFvYitHWUpK?= =?utf-8?B?ZDVHV0RqVFF5TUVGYXozS2pnYnhVRkV1NzlIeXUxL0xOR1ZyaDJoY0hEdEcz?= =?utf-8?B?RWU2NTl1bkE3aWVSeDZQRXF6NC90MGJTS25aRGlvS0tjNm1YdVRlVmxzY0R6?= =?utf-8?B?aDUxSVN1QmxpSVk1K2hXQWo0dFlINlc0eDA3aW9kakFDeTJRV2wwY0hwUGpj?= =?utf-8?B?b3FOdHZHNldLUFV2SSs1dktrKzFGWXBZckJKWDFPQlpRVitwSGt5WjVUZmEw?= =?utf-8?B?K3ZLVkY2TXRsVC9pU1hNRHZhZ3gvekMzd0lsZXdsM3E0MHJGMS82ZUJLOVNY?= =?utf-8?B?NGN3RWpKY3l2MEFNeXFKTDAxeklEMlpJOW12VFJoTTM0U3V6T0VNLzUxdTdq?= =?utf-8?B?ZFkvWWh5M3pSeHp1Z0R0NldqYlBmYTRCNnBmeFRENE0wbWNIZUZmendmbmZR?= =?utf-8?B?L2VTamV5d1ZaNExSczFFaGVYa0d2bzZxNzRTWnpVMGlpU0pCTVZNVEhjYmhj?= =?utf-8?B?NkQ0TWJyY1Brb0pPbGVmY045RmZ0YkxOaURya1R5eVRrY2JnWHZ4UDBmY1RJ?= =?utf-8?B?VDFiK3dNUXZxcFh3UHArbXovZEVPcnU3SFhJa2crd2NETEF5WmdzR3VJSVR6?= =?utf-8?B?SUhsODVGNHB6dTBXTDNMS1VkcHdnbkxKTm1HUW9QTzc0OVcwT3Iya1RmNis1?= =?utf-8?B?SEx2QjB2UEcxY0E4L2dvclIvVmM0NExKWUtYMTlqWExWVkR3dDI0cWMyNDUw?= =?utf-8?B?UzFRWTVOS0Jyck5SVHcxNW1CZ0Q4M3owREw1elMrME9vMzZ3ZmQ3Z3g1anY3?= =?utf-8?B?Ymp0dHV3cDAyaU5jT3JGOVZOVUhnQTdDZWZoYzNxODU4K3dPV05rRWdMTTNa?= =?utf-8?B?Q3MyM2VsTGwrUGhqNDVhMjdjR2w0MTRxM1YzMjh5SnNLSEtoV1NuRzl3bWRr?= =?utf-8?B?ZTRyNzlVUjl2cFNlbWtib1RCRWlPcW04QXNDN05CSW9sVm1QdElpYmsrZ21m?= =?utf-8?B?STNBRGQ5NmxSL29uNmtSUTFDY0dNOG1xZGhYNmlqeGtGOC9Sa2xGZkZEZ1Y1?= =?utf-8?B?OEp6MElxSGZlZjkwM0dDZjM5d01sRGFjNHZMWW5DSGFjR1FGNnJUb3FqY2Rk?= =?utf-8?B?QS9RVU16Ym0vaGFBdUY5SHYwaU5COVMxcmFITWNYTStjY2kySkozUWp6SkJ2?= =?utf-8?B?dEthQzd2ZzVqd2w3ZTFrYXRCdWxrUFpnOGh2a2NUOFpSTk5zbHFtLzNvK1ox?= =?utf-8?B?T0dWNmhCak9renFjOCt2WnpDcXlWVjdLbEJNUUhFYWpQNzlkZG9xczhCS1FU?= =?utf-8?B?eHNqbFlJZzY1Mm5LWHRQTWl6eU54MjBNMnZuU0FIMlhqMytOeG9FVXNzSmg0?= =?utf-8?B?VklnOFhJQWhMMDAxSW9FMXVuUFZpMUpkek5vVE84aEFockhaTDZQNDB4ck9i?= =?utf-8?B?RjJHbklDV3NEcGt6WWhVZ2c1Uk55S0l5VlBnV2gybXpvR1dIVEZSRzBhQjFM?= =?utf-8?B?OFlqK1RVZjB3WWc1REpHeWJUeVFnZUNXSlo5MDVpZkQ2dGp5K3p3cEFjMWlF?= =?utf-8?B?SlpJcDhSVlBvREd6UnJHOWVJZlZGeCt4aksycTVJdzhnTXdUSk9xMzJ4aHlL?= =?utf-8?B?eGFtd1h1VXUyaHg5aVdoR0FQR0VaTVZYTis1UTZaMU94R0I2ZmtzUENyNTV3?= =?utf-8?B?V3RWWU9JcjQ2ZmtJWm4xdU5Wa3JoaVVyU2EyZHZFdjlYU3hyQ2dqUGhjdVVX?= =?utf-8?B?SndKTDZZR3ZZT2JxWHZlczEzeEdZTStVSFZjN0M4bUJoVGlwNUplWkU5aHRi?= =?utf-8?B?Y0ZLMGoyR05wSW5oZXVIekVHdkV1SUoyNEFmY2Y0cC9VRWtSTllVUT09?= X-Exchange-RoutingPolicyChecked: rJsJoSQ2IugclAOKuKkWMGO63kQx1Z5FAWTFqtGNHW146Jij2AP5p8BuL8tL28cjKqxI0ZnPnefA+gt9V45m5v42HVhDF9P5cTRUVD3Sb41bjjjkvfKMIPtyp45bRdLFuKWApEhjA5aZ6I4s5ubiKVjq7o8uR6h/ySCXlXYlAqeD6Omf7KF5jlT3wUOQwldRIo5PrlhjdzZE2tJTV/XpY1Kgxjd2eSFpsMM/8WSgXQxgM9Ys5CZ8meOppolYY/JVnjJqZzfqBEy0Xh4HWjJ409uIRuwapdFrOJdGLiP12Grmhyb/jPXJzKO6z1rxGwHKJmd7LiwilGAXlkGJTmSqBA== X-MS-Exchange-CrossTenant-Network-Message-Id: 0f1471d8-e491-4e13-1526-08debadc67e2 X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB6020.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 May 2026 04:08:13.3324 (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: vSpRjzeq9xiWHIOlVPm8107PZI8tOBzZ9ZH9zv5LK9ZiAhiEG6qfmFQXfwdaPS9CAnHOg78HBkPau8rHh+ghSw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB4831 X-OriginatorOrg: intel.com Hi Venkat, On 5/26/2026 11:14 AM, Srikar Dronamraju wrote: > * Chen, Yu C [2026-05-25 23:35:45]: > >> Hi Venkat, >> >> On 5/25/2026 10:07 PM, Venkat Rao Bagalkote wrote: >>> Greetings!!! >>> >>> I am seeing an early boot kernel panic due to NULL pointer dereference >>> on a POWER9 (pSeries) system when testing linux-next (next-20260522). >> >> It seems that cpumask_first(llc_mask(i)) is accessing >> NULL cpu_coregroup_mask(): > >> has_coregroup_support() is false, thus cpu_coregroup_map >> is never allocated in smp_prepare_cpus(). >> This machine is a "shared system" VM. We should probably >> let the LLC id generation fall back to using L2 id if >> cpu_coregroup_mask is unavailable (which restores the >> behavior before this patch). I'm wondering if the following >> change would help(need IBM friends' help on this): > > Power9 and below systems, dont have coregroup. > Its not because of shared LPAR. But its true for dedicated LPARs too. > Only Power10 and above systems have hemisphere where we add MC/coregroup > support. > OK, thanks for the correction. Are you saying coregroup_enabled is false on Power9 and older hardware, and set to true on Power10? Power10 has a corresponding device-tree property, which is parsed to enable hemisphere support in find_possible_nodes(). This is why has_coregroup_support() returns true for Power10. >> >> diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c >> index 3467f86fd78f..cf6c2e4190ab 100644 >> --- a/arch/powerpc/kernel/smp.c >> +++ b/arch/powerpc/kernel/smp.c >> @@ -1042,11 +1042,6 @@ static const struct cpumask >> *tl_smallcore_smt_mask(struct sched_domain_topology_ >> } >> #endif >> >> -struct cpumask *cpu_coregroup_mask(int cpu) >> -{ >> - return per_cpu(cpu_coregroup_map, cpu); >> -} >> - >> static bool has_coregroup_support(void) >> { >> /* Coregroup identification not available on shared systems */ >> @@ -1056,6 +1051,14 @@ static bool has_coregroup_support(void) >> return coregroup_enabled; >> } >> >> +struct cpumask *cpu_coregroup_mask(int cpu) >> +{ >> + if (!has_coregroup_support()) >> + return cpu_l2_cache_mask(cpu); >> + >> + return per_cpu(cpu_coregroup_map, cpu); >> +} >> + > > While this is a work-around for the problem in Power9 > It will hurt Power10 and Power11 systems. > As has been alluded by Prateek, MC is not LLC on Power. Could you please elaborate on the cache topology? Specifically, could you clarify what the LLC is for Power9 and Power10 respectively? Is it always the L2 cache? I have checked the IBM documentation available at: https://hc32.hotchips.org/assets/program/conference/day1/HotChips2020_Server_Processors_IBM_Starke_POWER10_v33.pdf According to the document, a hemisphere corresponds to a 64MB L3 cache shared by 8 cores. Since the MC domain spans a single hemisphere, I wonder why the SD_SHARE_LLC flag is not enabled for the MC domain? > So by using llc_mask as cpu_coregroup_mask() we run the trouble of assuming > MC to be similar to LLC. So it will impact Power 10/11 Systems. > > In commit b5ea300a17e3 sched/cache: Make LLC id continuous, we define > #define llc_mask(cpu) cpu_coregroup_mask(cpu) > > defining it llc_mask to cpu_coregroup_mask means MC should be LLC. > This is not true for some architectures atleast on Power. > OK. > So shouldn't it be using > #define llc_mask(cpu) per_cpu(sd_llc, cpu) > > This should work for systems where LLC is sub-coregroup, coregroup (or super > coregroup: Lets say some archs want LLC at PKG and cluster at coregroup). > > if we do that, I dont think we even need the else case where we say > #define llc_mask(cpu) cpumask_of(cpu) > I suppose you are referring to sched_domain_span(per_cpu(sd_llc, cpu)). Indeed, deriving the LLC from the SD_SHARE_LLC level offers better scalability. However, this approach would involve scheduler domains, which can be truncated by cpuset partitions - a scenario we prefer to avoid. thanks, Chenyu