From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.20]) (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 ACE13371D0B for ; Mon, 18 May 2026 03:01:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.20 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779073311; cv=none; b=oioNgHoijx+npkg7mYLC9UKAfqcZaz0kl91oYzmQwQKTx80mPU/p6jxPnFhSQAq0KkxivSf+O4Zb31Y5v9dk2IMsU51oZQaUuh3AZ0T+GQbQbnAxzun9ZZPT7FOXcxXWGZqa8J/Jt20EUlLCk2nMcLQTK70WqljXAXZ9RDit4ng= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779073311; c=relaxed/simple; bh=jxyMasYhSoDoh+ySWermfeBo4xUbVISXFptZ1teUgGM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=q8mlV54Dw37jCz5K5s87kAJPcy+G9QjRqFY0uDAItr8zYG6Bb+T7lpIXl9q3hk3O2SpnlNYiSNamK4SCHjYkdFHf1WyWvm0cze5xw9w2Y+4fM3aWWqUiWmbNa9pHAwIwiGCaZaI81X8mFCNwx9rj1feRXbJicBatL26WPc7LcSU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=QbqTb7dC; arc=none smtp.client-ip=198.175.65.20 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="QbqTb7dC" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1779073307; x=1810609307; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=jxyMasYhSoDoh+ySWermfeBo4xUbVISXFptZ1teUgGM=; b=QbqTb7dCkQk20OvppdwH0Cib9xLchMg8dIpbBKjwer+SZPwn998lBYeg 0HHmgEwn+KPfK/AIiOhtc5IZDjOOW91R49zN9+NV/YP+zsXtsrJTNbYQe Z+8rd34tgnFYYIDFpVDlAwthSC6aanecANz/FNG4Gx9x9zPePY8te1+cF fjzhTHkl5nG+xN9z4QQboEv4+9toqD+hS5FBXgPSW2Vb3HK+j7w+XJ1ZT VQ+b20j9s6V6n/Wy3L1rlLF2MmFP+qnm7+OSKRcHIKJNOM6bPbEfYE4v4 Re6VraJoYs0ArRZkqOtRmLFqPtAXF0DeGIEuDgL83kGZOOcIw06LmMSZM Q==; X-CSE-ConnectionGUID: 644PxJjBRf2N9Evf7NcVrw== X-CSE-MsgGUID: xk8P7GqlTWaXVZ2zTCpwAA== X-IronPort-AV: E=McAfee;i="6800,10657,11789"; a="79637896" X-IronPort-AV: E=Sophos;i="6.23,241,1770624000"; d="scan'208";a="79637896" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by orvoesa112.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 May 2026 20:01:46 -0700 X-CSE-ConnectionGUID: nmEPUG+rSJCjsyqedbUYig== X-CSE-MsgGUID: KKM+8X38SuW7zKVYDzVhgw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,241,1770624000"; d="scan'208";a="238293692" Received: from ranerica-svr.sc.intel.com ([172.25.110.23]) by orviesa006.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 May 2026 20:01:47 -0700 Date: Sun, 17 May 2026 20:10:21 -0700 From: Ricardo Neri To: "Chen, Yu C" Cc: "Rafael J. Wysocki" , Len Brown , Tim C Chen , ricardo.neri@intel.com, linux-kernel@vger.kernel.org, Mel Gorman , Christian Loehle , Barry Song , Dietmar Eggemann , Vincent Guittot , Valentin Schneider , Ben Segall , Ingo Molnar , Juri Lelli , Peter Zijlstra , Steven Rostedt Subject: Re: [PATCH v3 3/4] sched/fair: Allow load balancing between CPUs of identical capacity Message-ID: <20260518031021.GA3865@ranerica-svr.sc.intel.com> References: <20260514-rneri-fix-cas-clusters-v3-0-0037869554bd@linux.intel.com> <20260514-rneri-fix-cas-clusters-v3-3-0037869554bd@linux.intel.com> <778c318c-ae41-4130-808e-0df4984e0ab0@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <778c318c-ae41-4130-808e-0df4984e0ab0@intel.com> User-Agent: Mutt/1.9.4 (2018-02-28) On Fri, May 15, 2026 at 11:16:00PM +0800, Chen, Yu C wrote: > 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. Thanks for your review! > Could I kindly ask why replacing > !capacity_greater(capacity_of(env->dst_cpu), capacity) This check only allows balance if dst_cpu has more than 1.05x runtime capacity than the CPU under consideration (i in the loop in this function). > with > capacity_greater(capacity, capacity_of(env->dst_cpu)) > does not achieve the expected effect? The problem with inverting the check is that it would allow balance if dst_cpu has more than 0.95x runtime capacity than the CPU under consideration, effectively allowing migrations to lower-capacity CPUs. > 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. Yes, it would meet the condition you describe, but also has the side effect described above. For this reason I decided to target the specific case of identical architectural capacity. > > thanks, > Chenyu >