From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.12]) (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 D32FD43DA56 for ; Mon, 29 Jun 2026 16:13:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.12 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782749603; cv=none; b=Vj37+0ncvchO1fuxO2m4D8ocbg97uNwYzNjOOrqx8ywY0qG4n9Q3zZcrRr1QzFlmK/LDNHRDA4fCalbX4ZQqW5Bimqfxyia//FlwZs3xmDteEvcYl6b7B6/UaBLUEz/jK8nsRhM1BpnD159n/UPY5i37MoM1B4O9aSxaIIUvKfw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782749603; c=relaxed/simple; bh=uFPWJ3cXJ8ADN1DQkeKyLVsoZ/glO7XWArn7hISsqco=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=patr6xMqes8WMeiUjHmic9+RKpN5DDJD+qWLeP2p/fuq6TTjgpSiTtz8F2uHs6PfoH1O0ynm3iq3t83+NUz/+Mpmbn8Cmx/TWh/AtRlW2dohWMaAHogZbdrKwSX70AjONoJG5bATX+eYjUltTwIXdSy+ZPncfAnvfnYPsdg1cM0= 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=inP/XbEl; arc=none smtp.client-ip=198.175.65.12 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="inP/XbEl" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1782749601; x=1814285601; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=uFPWJ3cXJ8ADN1DQkeKyLVsoZ/glO7XWArn7hISsqco=; b=inP/XbEl0Vb1k7MW9wTafk1VqPwbTk8ruWJ1NMs7JBEk+5jo3MCJ/UmP 1A/EZOzmBc6Mn4EVGeY0VrXhjbapmD20F7f1NTVihREBllgJizYLJIZ9a p9vSwwPq19VFfq/Hk2BeRewKClRJpFQnWMMb/RzzFCoH7nAQmWCmcIOxT Pjkjr3HqSCwGrA8yztrESI34W6O/94VfbqpMxB5WBrkq/C1EA9bhAgGKX ksEXlCVXLQiezZolnZ4voJJaf/6+alvmnREfAPmmbn/ytB2S+0cj0m2Yr 2HcceugFOUAb+CxXoxLA2WVPMTzblB+gsI0uqo42+GAgjQfkq9g0/ytOL w==; X-CSE-ConnectionGUID: BJTbAcpqS661rOEQh+NOuw== X-CSE-MsgGUID: DQNY0SEJR4WfHrSR9XRU8g== X-IronPort-AV: E=McAfee;i="6800,10657,11832"; a="94939074" X-IronPort-AV: E=Sophos;i="6.24,232,1774335600"; d="scan'208";a="94939074" Received: from fmviesa002.fm.intel.com ([10.60.135.142]) by orvoesa104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Jun 2026 09:13:21 -0700 X-CSE-ConnectionGUID: swi/rcO1TKKaW3r2MidWZA== X-CSE-MsgGUID: 510BzkSgSTqi94fTaZ2zew== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.24,232,1774335600"; d="scan'208";a="275226804" Received: from ranerica-svr.sc.intel.com ([172.25.110.23]) by fmviesa002.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Jun 2026 09:13:21 -0700 Date: Mon, 29 Jun 2026 09:22:41 -0700 From: Ricardo Neri To: Andrea Righi Cc: Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , Tim C Chen , Chen Yu , Christian Loehle , K Prateek Nayak , Barry Song , "Rafael J. Wysocki" , Len Brown , ricardo.neri@intel.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH v5 5/6] sched/fair: Allow load balancing between CPUs of identical capacity Message-ID: <20260629162241.GA23570@ranerica-svr.sc.intel.com> References: <20260622-rneri-fix-cas-clusters-v5-0-19968f2d1497@linux.intel.com> <20260622-rneri-fix-cas-clusters-v5-5-19968f2d1497@linux.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: User-Agent: Mutt/1.9.4 (2018-02-28) On Sat, Jun 27, 2026 at 09:07:19PM +0200, Andrea Righi wrote: > Hi Ricardo, > > On Mon, Jun 22, 2026 at 05:05:55PM -0700, 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. > > > > Tested-by: Christian Loehle > > Signed-off-by: Ricardo Neri > > --- > > 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 e55eb019d2c9..f4eb55cad54d 100644 > > --- a/kernel/sched/fair.c > > +++ b/kernel/sched/fair.c > > @@ -12992,13 +12992,20 @@ static struct rq *sched_balance_find_src_rq(struct lb_env *env, > > */ > > if (env->sd->flags & SD_ASYM_CPUCAPACITY && > > nr_running == 1) { > > + bool same_arch_cluster = static_branch_unlikely(&sched_cluster_active) && > > + (arch_scale_cpu_capacity(env->dst_cpu) == > > + arch_scale_cpu_capacity(i)); > > I find same_arch_cluster a bit misleading. It sounds like "these two CPUs belong > to the same cluster", Indeed. > while what it actually checks is whether a cluster > topology exists somewhere in the root domain and the two CPUs have exactly the > same architectural capacity. Am I understanding it correctly? Yes, it is supposed to mean this. > > If so, would something like same_arch_capacity or cluster_equal_capacity be a > better name? I think either would make the intent of the code a bit clearer. Sure. I can change the name. I think a name reflecting the same capacity as you suggest would be better. The name would have to change anyway because in my next version I will use get_actual_cpu_capacity() as Vincent has suggested.