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 6D0F9322A for ; Tue, 23 Jun 2026 07:45:30 +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=1782200733; cv=none; b=m16yluFP598rb/pk7kceM7643ouDMCcracsUZU1vtS2JdjcQFvXewA1t3eZCVTiKos3SlgAwNmKXh9ew+FUVDoILjzHsnsoIHh42ftBddHRf0rpo9e9PxWUGxcwDkwOpGD7m8MKrOSzO56LXXaXVx93jFMW/JTV+UoNln8TrZys= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782200733; c=relaxed/simple; bh=UMtJEX8W2ZnqV1/6YQL/tIWARo3DxW9UMW5B9+Lmc2Q=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=n8ykgLIV5qWLLLk3jQou4JUeNoRnJC9skVJUMcJMSTxlV/8lg+CUvIxxoeG70FVyWHG0gZJgCp4OE2C3qGgR68VR17ymkwQJDkRTPRhD7yDxDc2UyuSYrwRoU5h798MgAFH50Ek/IRMTKH1nEmcBY7UQVNJDBFH/U7NubyrkqA8= 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=O/+zSnVd; 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="O/+zSnVd" 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 B61631A25; Tue, 23 Jun 2026 00:45:24 -0700 (PDT) Received: from [10.1.27.69] (unknown [10.1.27.69]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C8CBB3F836; Tue, 23 Jun 2026 00:45:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1782200729; bh=UMtJEX8W2ZnqV1/6YQL/tIWARo3DxW9UMW5B9+Lmc2Q=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=O/+zSnVd6flX5L1yklqCWuBc0I0LydDJTMUclZ+AmSrKsJ5LmYyxzNvBx6Ff+rqHa zyakt04HXfsWtq11bpM9DXnyNZ2cq7a8gpFMCEwK2vh/PgOTCMsY2ou4K3KURv88G3 GVHwqtwq0E0LrLJTXZMSCbK4ziZILI3YoOx6BXmA= Message-ID: Date: Tue, 23 Jun 2026 08:45:23 +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 v5 5/6] sched/fair: Allow load balancing between CPUs of identical capacity To: Vincent Guittot , Ricardo Neri Cc: Ingo Molnar , Peter Zijlstra , Juri Lelli , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , Tim C Chen , Chen Yu , K Prateek Nayak , Barry Song , "Rafael J. Wysocki" , Andrea Righi , Len Brown , ricardo.neri@intel.com, linux-kernel@vger.kernel.org References: <20260622-rneri-fix-cas-clusters-v5-0-19968f2d1497@linux.intel.com> <20260622-rneri-fix-cas-clusters-v5-5-19968f2d1497@linux.intel.com> Content-Language: en-US From: Christian Loehle In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 6/23/26 08:20, Vincent Guittot wrote: > On Tue, 23 Jun 2026 at 01:55, 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 > > capacity_of() reflects not only RT and irq pressure but also thermal > pressure or system frequency capping. > If dst cluster is under thermal mitigation but the source cluster is > not, we probably shouldn't spread tasks across both clusters. > Have you considered using get_actual_cpu_capacity() instead of > arch_scale_cpu_capacity() ? Replacing arch_scale_cpu_capacity() with get_actual_cpu_capacity() would make the == comparison below very unlikely to be true FWIW. I think it's fine like that, I will prepare a follow-up anyway to make it work for our "almost equal capacity" cluster systems and then also consider switching to get_actual_cpu_capacity() since we include a margin anyway. > >> 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)); >> 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. Use architectural capacity to ignore >> + * runtime variability. >> */ >> - if (!smt_degraded_cap && >> + if (!smt_degraded_cap && !same_arch_cluster && >> !capacity_greater(capacity_of(env->dst_cpu), capacity)) >> continue; >> } >> >> -- >> 2.43.0 >>