From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.16]) (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 B219C3CAE76 for ; Fri, 15 May 2026 15:16:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=198.175.65.16 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778858183; cv=fail; b=uETIk79j8Y8ljZNy/ei0IAMr7sauVad84lemV/mDEdG4z7MvCJvcdY5rRfgQPX/Papdgt0SNaOevPInuJu1YuHBe9f+e/nC5OmQxk9CB2BYNO8wT0bndRAWrEU3NCeWxgfDYFJTd5f6HMwbR7XQIZlWEgbLGGxsGiPn9vhpz3kA= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778858183; c=relaxed/simple; bh=DZWh0vWYfKdnt0q9uyfxN6kacc8pcFDOUEfhI61Cl7g=; h=Message-ID:Date:Subject:To:CC:References:From:In-Reply-To: Content-Type:MIME-Version; b=QbWYBQMEZ2n8n5iqrqFRWgB7DkHhDmy/yjywgNBE4sJ+7GK6fM61CEYwLx4wX7fCuyLJM0IY8Kazl/qUeOTWPt1ckZ7xALUZdnKpdVDKsFMmueINQPag4ARYcc/BL3MN5Db/rB4k4e+oJeS+3ldckIGgYwDK4L4Hxa3169O1Cd0= 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=NuADeN4z; arc=fail smtp.client-ip=198.175.65.16 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="NuADeN4z" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1778858180; x=1810394180; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=DZWh0vWYfKdnt0q9uyfxN6kacc8pcFDOUEfhI61Cl7g=; b=NuADeN4zkU3pyY/Mpmrdqq5674mj5hAcJNxlhzgKMxhnyt8r+EqeprYk PoIi2B6nvza5nGknl8phYUhcUOQq+fx9GDF8oMYu9iphVufwAhZrFb5bS NIzRs9EcQrQe1UAtrUeJ4itlNiDfQHsMY0T+ZlmUqOLzGsmSpb9Ua4qOH AzR0eF8uUTKs9Jv1Ef/CPrTNuNRNZKxcFn4EW0YZyYjLuFNeFO4FroYo6 RcP90sox/rtNF2NdhKUrkmHEEe7k0e61SdN2PS0SIeJj1lB8knfmcY5Jn qFtQNUy1UjuNI8vy8rBShddONeyTF72kQQxIFEtsEszQVX3BEKvcr4yQ0 A==; X-CSE-ConnectionGUID: VeFPrRZ7R8WjoLC3o4B8YA== X-CSE-MsgGUID: YC+O6sboTp2ySMSEYoa39g== X-IronPort-AV: E=McAfee;i="6800,10657,11787"; a="79985093" X-IronPort-AV: E=Sophos;i="6.23,236,1770624000"; d="scan'208";a="79985093" Received: from fmviesa003.fm.intel.com ([10.60.135.143]) by orvoesa108.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 May 2026 08:16:20 -0700 X-CSE-ConnectionGUID: 7YZPDNZZQSWKZ+c+M4sZKA== X-CSE-MsgGUID: 7AeEpuA+S8aQ7GNhMsmxdA== X-ExtLoop1: 1 Received: from fmsmsx902.amr.corp.intel.com ([10.18.126.91]) by fmviesa003.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 May 2026 08:16:20 -0700 Received: from FMSMSX903.amr.corp.intel.com (10.18.126.92) by fmsmsx902.amr.corp.intel.com (10.18.126.91) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.37; Fri, 15 May 2026 08:16:19 -0700 Received: from fmsedg903.ED.cps.intel.com (10.1.192.145) 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.37 via Frontend Transport; Fri, 15 May 2026 08:16:19 -0700 Received: from SN4PR2101CU001.outbound.protection.outlook.com (40.93.195.3) by edgegateway.intel.com (192.55.55.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.37; Fri, 15 May 2026 08:16:17 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=IIMENzsrEEqO2dPWAk38EabJAPRVoDrneIg1MwmPHp8K8gR5NU7faxn1SlEFujbBXLJUr8jQyjvmlqTsSecpcBBE73ZIru9nq56iadRS9+4m7blObnn2EGu8Ul/Pf4OP9Nrg/j3h4JyuofjwiDk1hPe1ks1SlcuEHG8q3D4W6q6dHXDiJ1/1hp+mkJydN5dqD9mAL5EKk0HqLgFSqO9+N/+qu7xbPoMss968NzEKYSylfoKcWSApEuhyWkpHAGtw0KmfK4i+OSjbaDDo2chlZKFLgt4KRywR1bpKFVybStuTp7gXhm9R8tK3zm+Na53rt3C5bnqZ/MmYJpVQBzTueg== 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=jb5QIurcABOgHWzxfNzCX4ofd0SndHtjdw36Fg7tI0U=; b=fD+/9h/kYwg5n79vImPer7tPQNPNfyyAOO0jnfg4Dl+x8xi0xyh8PoNbc8/vu6D64fCzgJwOf3LIRLNDX68kk85E72gQBl7tHLvcdIBTqrIyHT1q8d3wYuLHRkM6ZlzxJDCjwzH22DDsmFk1JHZ7JFfF0Hw/qNM6V84xrJdt4TlA/zWk8fDrcRQ1WBDcRXFfDyudHhHMQ3PBE2OHkmycxgOwYehtFfQ6tw0CYnsine3PS4A4N8xAIm318+A3BhgcoUY8OcXA1IBnol2/quVgIrNBO7Y1yx6fz49mnVj0jFs0gCvPMvxPbDYCIcrLMt4SkCLx5bcXXDQzruoaqdioiA== 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 LV3PR11MB8484.namprd11.prod.outlook.com (2603:10b6:408:1b4::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9913.13; Fri, 15 May 2026 15:16:09 +0000 Received: from DM4PR11MB6020.namprd11.prod.outlook.com ([fe80::3058:1480:e4ac:5765]) by DM4PR11MB6020.namprd11.prod.outlook.com ([fe80::3058:1480:e4ac:5765%6]) with mapi id 15.20.9913.009; Fri, 15 May 2026 15:16:09 +0000 Message-ID: <778c318c-ae41-4130-808e-0df4984e0ab0@intel.com> Date: Fri, 15 May 2026 23:16:00 +0800 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 3/4] sched/fair: Allow load balancing between CPUs of identical capacity To: Ricardo Neri CC: "Rafael J. Wysocki" , Len Brown , "Tim C Chen" , , , Mel Gorman , "Christian Loehle" , Barry Song , "Dietmar Eggemann" , Vincent Guittot , Valentin Schneider , "Ben Segall" , Ingo Molnar , Juri Lelli , Peter Zijlstra , "Steven Rostedt" References: <20260514-rneri-fix-cas-clusters-v3-0-0037869554bd@linux.intel.com> <20260514-rneri-fix-cas-clusters-v3-3-0037869554bd@linux.intel.com> Content-Language: en-US From: "Chen, Yu C" In-Reply-To: <20260514-rneri-fix-cas-clusters-v3-3-0037869554bd@linux.intel.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: TPYP295CA0044.TWNP295.PROD.OUTLOOK.COM (2603:1096:7d0:7::18) 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_|LV3PR11MB8484:EE_ X-MS-Office365-Filtering-Correlation-Id: b6f75c8c-f476-407e-5999-08deb294e4ab X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|7416014|376014|1800799024|11063799003|4143699003|56012099003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: O/EAkOhYSKjTZ5vzAw9mOykzLf6d8VwIme0kviPuckVEvzJBONXLXlpjVGSq+QpFF0bMXgELHEZjRHzUQsjDltqwT0GBDCNs8WYGI4CIp4XoEyVuZ/s2Sg4W0N8r4yjS+Wt1l2XCmrrEbWzB1hnP9YcJvdKx5LEHS3IUoFczNIqL1B9FXo/pkuNcebgCcdsr2RjmzZpPz4AkA0ICS0JpYP2+UrgTdN6Pz7KVjDPvzetxVf+EQcDsM8bnwKnkrHWyLPJLZy+TUkioUTa+GRKtWsHV4dxi4iprB127qq2+GB3aCEIUWLlOyibKKVWgMbBn7g/Hm5OorRgh40181/4Y3u2R216I3GwVSxefuoAkHo3T1+oOiiN0i6wWlLIKoWj3sqZNiLSGwD3AGlCrnXj2lKN1CYNa/Dy6TqFm+bTzizcqlOZZWnATQaRWEB8Lrn6mLxAmsdmR4DPCSG6CizAyll1HWcTywRMDsezaUAVeeqMhOVgD3ZHt0HUFEnRA1EntcWBx1tkGyYNYeoV5AugbE4xmMJ9kMJ1gEr71jCYz/jQ/PMTB72/Ni1jwQifzv731Peu+WLv4CxRSHxWGnTomZOhCPBXiH45w0Mf5njbMugd4uGjpoSLkNqLon9aI4pfY+RtRrL+3DOLSLgG3d6Z+PQin4EQq/oe+pz9UdtDTD8FdozqFe/IP97K3Mk9KidXZ 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)(7416014)(376014)(1800799024)(11063799003)(4143699003)(56012099003)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?YjZRYSs0R094MUJXSkRpZnppMklQK1l3Z0lEV2V0RTlub3hwWmNRWndmb2lZ?= =?utf-8?B?TEUrcnJBQjNYY2NYYnB4VHlIK0wyMVByQ012ZUw1N2JqT2ZWUzI1MGJUYjFn?= =?utf-8?B?MkdIT2ZxeXhPc2NFU2pFc0YvRk14VkYxeE5mR3ZCaVVLQ25jNmNXVlY0S3A4?= =?utf-8?B?TU5KRk1tT0czWWFjdHJTUFMrL2FOUmRFYk93cWF4VnVPc3E0R2VXRHpENGRn?= =?utf-8?B?bUR1Z1FtTjVaN0ZUWUZpbmVmOTNwQ1AvTWFvWFhsaE9hKzhJRDFORVBydlc1?= =?utf-8?B?U001MVFQY2hQWXZ6cXVETjVnUjg1L3VQNVR6M0FsL0ppMGlVQ0J3ZnNqSWhU?= =?utf-8?B?SFdKcmRPSnZsNHYwSWlEdlBITGkvWGtieU4xSmh2MkFLaTB5Q3ZVU1NLdC81?= =?utf-8?B?V0pRcGRnRnByWEhaZDFDK2hqVGlDSXlHaUEybHo0V1VyZDhla3U3aU4vVkdr?= =?utf-8?B?TzlGSEpROHQ3U2svVzVYd3lScWJUYklZTkE4N1R0WmYwNjFPWDZ1SFlITkNm?= =?utf-8?B?aXpzV0ltcUhDWTVScDJKcXYzZEtSQXBSQ05Sd3Q1MWtQNXhYRE5rYVBiUlRv?= =?utf-8?B?bXhGei9sRWRJYm9FaUZTMjVoL2tzQ2FVbDF1dXkzUmdTc2RzSG9VZkVOaHJp?= =?utf-8?B?NDlvK3U4NGZ6TCt5TjFFb0JDb1ZteUpHdVE5T0Vhb05HTkNtTVNDZ25iR1Zq?= =?utf-8?B?MTlRWGdXUjhtYk04WkJaRTFFYkFjUjFBRWpVWWcvbW8vVnV0d25zL2ViMSt2?= =?utf-8?B?NHVvczB3cjNQbnhHRVFzNFZtNUpKeStKSjJoYW5qbG9yTUZ1NzhZMDJsSzU2?= =?utf-8?B?QVVVZHF3OVZuWjI3dFNGQUlHa0dSMFROUWdiL2I4OWpDWVQyajhnQllMYzdG?= =?utf-8?B?K2JkanA1M2UvNThJN1Vmbzl1N2FqcWZEVU5FOGk0RjBnRWN6UkFNaUZaVEFF?= =?utf-8?B?L0ZDYTc4SC9tQ2xwZGN4NmdCYWdGZndqL3dWTlEzL2hKc2lHQkhPbkQ2WVRn?= =?utf-8?B?d0ExelRUZnd1VEYwYzhPZlQrR1oxT21XQ1QvcnFLblJQZ1hoRlJvMFMzNFYx?= =?utf-8?B?NXVadjEvejVwa1hTTi9RQWF4ODlkSjV1NmFEMUNpNEF3YzFkS0N4WkkybTlD?= =?utf-8?B?ZnZ6QzZlTWJUemFMSWcvaHdHcisvSVNFU280ei9YWjlDU0JjWTJYSDhZZUZG?= =?utf-8?B?MHlncU9nRkJZYnRKUkFuRzFnOVdPSjlkNDNCTDZJZ1I4c0o5MENjd3pKZG1w?= =?utf-8?B?VDlJMFppRkIwdi9uQkFWeENlWTFlT0VMN0NBVmJUSlV0eXgzWkc0ckxtZlJo?= =?utf-8?B?NDByMTBKYW5VR3dSV0RmQmlSdjE5UE1xeHpDVmJwYzI5MFNGVThqNDZwZ2h2?= =?utf-8?B?V01hcForWVFkNlprREtZNHlxZmFlVWQ0dysrOE1STXdXaVhaMnNFUklFeElJ?= =?utf-8?B?RExzengrT1J2UHJrR2xWcDV1R2xQV3VuSTl4L3A0NDllZDVTZ2RIU0QzcjhN?= =?utf-8?B?RkxZS09zU25Lb0x4QjJ5dU9IdkJ2QUZFN2NKMEE2NzBLV0N1ODRhWEFQQXls?= =?utf-8?B?Sm1BdGFZQmU2VEVtT21Zb2xUb093S0JCREJkZS9laCswc1Zza2pVa2crSjZJ?= =?utf-8?B?eEpPWmRQS3FNWjNoc2dhdDh0WWU3aTBaenRCOUJEOThTWHJSa3ZLUHdTa2VY?= =?utf-8?B?UjNMZGgwMVYvZFlxZG5rYkNnbklHTHF3UVMyNDFBblY0VlFFU3BwSi9kVlYy?= =?utf-8?B?NGUvc2RaTkhFTmc1QnNIUjhWMzNYTTA0YkozTGphRkZYVkNGaFBPWDlHeTRJ?= =?utf-8?B?YzIrUVpLbTJZdXFKenZsb0hTNUxsVzlqckJPSTdFbFdnM09IQ1dJZklzUkdj?= =?utf-8?B?TWZLRlNUK2tXMjJMNk9rcHVpWG9zUjFhaEhJTW1xeTM1NEQySlF6aU85YnhT?= =?utf-8?B?NnBJb3F2VmwwbnBGbnJtZkdjd3FQVDBWNU9TdEUvaDBYaFdtZ3kxK245S0Iz?= =?utf-8?B?VC95S1VMdWJYcjVtN1UwUG9ySStMdVNLSW9VVW5MY2YzbFdob3lpRldIMUlt?= =?utf-8?B?cGpXTUI5NjRBTWhMTjh5NE1IWHhHc3hVb2E3NkF3MjM2QjJlMnI0K3hqQmUw?= =?utf-8?B?akNId2o4VkVUbVdzdDA4aWhZK3BXWUhnajBjVTV2VmdQVDRwRzZrQUFaSE85?= =?utf-8?B?bWlIc0hFd2wrMVRLMU1IbGw0aVJCMHBaNUR0c1pPOHNkNm51UHMwUDRiY1Rh?= =?utf-8?B?N1VZdCtOWHVRcVE4Skgwdmp1azVFdDNDWGEzV3dadm1FcGVuWEhWeFNCVkJm?= =?utf-8?B?TFR0V3J1cGhWSm8vbXROTXFzZEVJeENReDVCbXFMUGhjN2JybHRKUT09?= X-Exchange-RoutingPolicyChecked: HZE4e9Ca1Zl0OGVxjNZXel0Wf4cd9E0eX3+dDX9S8pRKxyjQ4TGuu98KBWPrWzx2X14JK0EcIJEE9jUDT2jLd9B9446ObLLBhrvC9MbWLz2X5msTC9FhP0t1Z37ORL9i38jHJhWlml9/doMgbcGTrjRMnr4H3AmrtASQRye+EfLYVXLga4QqmZaAU2A8f5Nw3W+poMRU2s4SV5myRnoHeRi/jo4wZyNsO+3SjkHi3Xm8K1+b+xAGDUG2DwPXnSIsM+gh+ubh6vt5tI6B6ZTrBaSaHxiBUai9B5Q3BCjttNZkxUTIefnHbJ9L/BqnDfe3bMNJ0QhvS5mBB/Bhkb+Viw== X-MS-Exchange-CrossTenant-Network-Message-Id: b6f75c8c-f476-407e-5999-08deb294e4ab X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB6020.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 May 2026 15:16:09.7177 (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: hzFO3q322EcCDkSYUbXLvQASzkRkBcIrCXSTryuHLHZzpQm7bGR3gWSuSlDeu/8uHPRpdTj7QDJ8R1RbVfUUEg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR11MB8484 X-OriginatorOrg: intel.com On 5/15/2026 2:34 AM, Ricardo Neri wrote: > sched_balance_find_src_rq() avoids selecting a runqueue with a single > running task as busiest if doing so results in migrating the task to a > CPU with less than ~5% of extra capacity. It also unintentionally > prevents migrations between CPUs of identical capacity. > > When CONFIG_SCHED_CLUSTER is enabled, load should be balanced across > clusters of CPUs with the same capacity. Allowing migration between CPUs > of identical capacity is necessary to meet this goal. > > Use arch_scale_cpu_capacity() to reflect architectural capacity, excluding > runtime reductions due to side activity or thermal pressure. Guard this > check with the sched_cluster_active static key so that systems without > cluster topology are unaffected. > > Signed-off-by: Ricardo Neri > --- > Changes in v3: > * Reverted the inverted capacity check; the inverted form incorrectly > allows migrations to CPUs of slightly less capacity. > * Guarded the check for architectural capacity with the > sched_cluster_active static key. > > Changes in v2: > * Used arch_scale_cpu_capacity() instead of capacity_of() to ignore > runtime variability. > * Inverted the check for runtime capacity. (Christian) > * Reworded patch description for clarity. > --- > kernel/sched/fair.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index dcc02ceb44b5..d2a4c529f67f 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -11846,8 +11846,14 @@ static struct rq *sched_balance_find_src_rq(struct lb_env *env, > * eventually lead to active_balancing high->low capacity. > * Higher per-CPU capacity is considered better than balancing > * average load. > + * > + * CONFIG_SCHED_CLUSTER requires balancing load across clusters > + * of identical capacity. Use architectural capacity to ignore > + * runtime variability. > */ > if (env->sd->flags & SD_ASYM_CPUCAPACITY && > + (!static_branch_unlikely(&sched_cluster_active) || > + arch_scale_cpu_capacity(env->dst_cpu) != arch_scale_cpu_capacity(i)) && > !capacity_greater(capacity_of(env->dst_cpu), capacity) && As stated in the commit log, the existing logic blocks task migrations between CPUs with identical capacity, which is based on capacity_of() comparison rather than arch_scale_cpu_capacity. Could I kindly ask why replacing !capacity_greater(capacity_of(env->dst_cpu), capacity) with capacity_greater(capacity, capacity_of(env->dst_cpu)) does not achieve the expected effect? This would theoretically enable migration among equal-capacity CPUs, and in most cases e-cores in different clusters should return 0 thus load balance is allowed. thanks, Chenyu