From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 267FD3DEFF0 for ; Thu, 23 Jul 2026 07:11:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784790669; cv=none; b=SGYMkUUVj8NbgVtpMYuz3zBWfk1UvhqKE6ce/NLGUcBoML/o4zI7gB5XkaDGcVkkg0CORd9cLwbYPtqEPWgdpBv1OztOn+IefHuMKNPKwxKum7Bm8eQgupYnRgSMw+1vpkXYi35jVkehSe+o8U4T48g9jNPZUJtPNcTx4vxgytY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784790669; c=relaxed/simple; bh=OH0VRt2+l+hy0vA/CpgMtqNe53dVSy6u7mX7lKVVJpY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=L9BudZRMlwpILTKcEOSzySTC6dsPmJ1i3TsetTcJSiUpFEd6GqwRe/T7kMSXpnrWqji0qO02yCZStHMC515EKQJuJDYLpsHcPaX2Swu3YsZSRjmlCr5ZboYKbNAqpTRfrthnq6hzsxNbIl8ROWv5Sar77wEHrz7ydbOR1QZEJvU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=DIBbePSG; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="DIBbePSG" Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 58DE51BA8; Thu, 23 Jul 2026 00:11:00 -0700 (PDT) Received: from [10.1.39.91] (e127648.arm.com [10.1.39.91]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 79E133F66F; Thu, 23 Jul 2026 00:11:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1784790664; bh=OH0VRt2+l+hy0vA/CpgMtqNe53dVSy6u7mX7lKVVJpY=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=DIBbePSG4V4HeLdQSBqQlyN2TaKVBXImsT2ygzx6VxtrSguxP3UMO7P9IyQsWcvYe vSC6cmh/LLmBo6cDci0ctgfC9csyY2xTcSa77Mfm5HA5NyMYmm4aaxGqpT8u1GnBxj zNzLntwgKZdPV8Uk4gukbaH73Qd8URf9rwwf/g9s= Message-ID: Date: Thu, 23 Jul 2026 08:10:59 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 5/6] sched/fair: Allow load balancing between CPUs of identical capacity To: Ricardo Neri , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , Tim C Chen , Chen Yu , K Prateek Nayak , Andrea Righi , Barry Song Cc: "Rafael J. Wysocki" , Len Brown , ricardo.neri@intel.com, linux-kernel@vger.kernel.org References: <20260720-rneri-fix-cas-clusters-v6-0-bb500bf4afd4@linux.intel.com> <20260720-rneri-fix-cas-clusters-v6-5-bb500bf4afd4@linux.intel.com> Content-Language: en-US From: Christian Loehle In-Reply-To: <20260720-rneri-fix-cas-clusters-v6-5-bb500bf4afd4@linux.intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 7/21/26 03:43, 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 get_actual_cpu_capacity() to reflect architectural capacity as well > as diminished capacity due to hardware or cpufreq pressure. Guard this > check with the sched_cluster_active static key so that systems without > cluster topology are unaffected. > > Tested-by: Christian Loehle > Tested-by: Andrea Righi > Signed-off-by: Ricardo Neri > --- > Changes in v6: > * Switched to use get_actual_cpu_capacity() instead of > arch_scale_cpu_capacity(). The former considers rq->avg_hw.load_avg and > cpufreq_pressure and their impact on CPU capacity. (Vincent) > * Renamed the variable same_arch_cluster as cluster_equal_cap for > clarity. (Andrea) > * Added Tested-by tag from Andrea. Thanks! > > Changes in v5: > * Optimized logic to identify same-arch clusters only when needed. > * Added Tested-by tag from Christian. Thanks! > > Changes in v4: > * Implemented the check for cluster with a local variable for improved > readability. > > 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 | 9 ++++++++- > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index feea47e6abea..de4189b562ac 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -13104,13 +13104,20 @@ static struct rq *sched_balance_find_src_rq(struct lb_env *env, > */ > if (env->sd->flags & SD_ASYM_CPUCAPACITY && > nr_running == 1) { > + bool cluster_equal_cap = static_branch_unlikely(&sched_cluster_active) && > + (get_actual_cpu_capacity(env->dst_cpu) == > + get_actual_cpu_capacity(i)); I guess it's extremely unlikely, but it _feels_ wrong to have to clusters of different arch_scale_cpu_capacity() equal to true here because of system/thermal pressure (which is obviously considered more transient). Adding && arch_scale_cpu_capacity(env->dst_cpu) == arch_scale_cpu_capacity(i) might even make the check cheaper because it's better for the branch predictor than get_actual_cpu_capacity(). Vincent, would you be fine with requiring both: equal get_actual_cpu_capacity() and arch_scale_cpu_capacity()? Given how unlikely it actually is in any case: Reviewed-by: Christian Loehle > bool smt_degraded_cap = sched_smt_active() && !is_core_idle(i); > > /* > * Busy SMT siblings reduce the capacity of CPU @i. Do > * not skip it in this case. > + * > + * CONFIG_SCHED_CLUSTER requires balancing load across > + * clusters of identical capacity, accounting for > + * hardware and cpufreq pressure. > */ > - if (!smt_degraded_cap && > + if (!smt_degraded_cap && !cluster_equal_cap && > !capacity_greater(capacity_of(env->dst_cpu), capacity)) > continue; > } >