From nobody Wed Feb 11 07:49:27 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6D0DAEB64DA for ; Fri, 7 Jul 2023 22:57:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232526AbjGGW5M (ORCPT ); Fri, 7 Jul 2023 18:57:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60502 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229773AbjGGW45 (ORCPT ); Fri, 7 Jul 2023 18:56:57 -0400 Received: from mga06.intel.com (mga06b.intel.com [134.134.136.31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 01FDB1997 for ; Fri, 7 Jul 2023 15:56:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1688770616; x=1720306616; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=5zfJiUCxKx+vvs3EQDbGAx5BcCZrMXvlpEj7Tybxxd8=; b=RPNliaAUxakcnm1hZc90AvVq+VEx2qAAeCE21roAL/8WcWRXnfDcmuUj hRnkV/MJOBRyP3TJOL9f5qf3NzTEag2VohqyrSv/BXx/Ugrq2mjrErAx5 PWrvk2CSCn4hdth7c75NYumyjkARMADJEjxzQJFt+Avdjqg4YJgaZtpUI YGvKxOXwHJ1R35sunOQCGPm61+2X/VhHGsczeVKHojRQuvbuzW/yvMjtt AIaQs+GIkypSGJWfsYQg0vNC2Y3w6ldqx9O5s3KuK8Fack1w5LfukAVQm K8saeyuF47VQhzpw414mzCkBN1D6kmZBqrwCc1q7xFNFIT0wsHRe0fkH9 Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10764"; a="427683492" X-IronPort-AV: E=Sophos;i="6.01,189,1684825200"; d="scan'208";a="427683492" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Jul 2023 15:56:56 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10764"; a="714176674" X-IronPort-AV: E=Sophos;i="6.01,189,1684825200"; d="scan'208";a="714176674" Received: from b04f130c83f2.jf.intel.com ([10.165.154.98]) by orsmga007.jf.intel.com with ESMTP; 07 Jul 2023 15:56:56 -0700 From: Tim Chen To: Peter Zijlstra Cc: Ricardo Neri , Juri Lelli , Vincent Guittot , Ricardo Neri , "Ravi V . Shankar" , Ben Segall , Daniel Bristot de Oliveira , Dietmar Eggemann , Len Brown , Mel Gorman , "Rafael J . Wysocki" , Srinivas Pandruvada , Steven Rostedt , Tim Chen , Valentin Schneider , Ionela Voinescu , x86@kernel.org, linux-kernel@vger.kernel.org, Shrikanth Hegde , Srikar Dronamraju , naveen.n.rao@linux.vnet.ibm.com, Yicong Yang , Barry Song , Chen Yu , Hillf Danton Subject: [Patch v3 4/6] sched/fair: Consider the idle state of the whole core for load balance Date: Fri, 7 Jul 2023 15:57:03 -0700 Message-Id: <807bdd05331378ea3bf5956bda87ded1036ba769.1688770494.git.tim.c.chen@linux.intel.com> X-Mailer: git-send-email 2.32.0 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Ricardo Neri should_we_balance() traverses the group_balance_mask (AND'ed with lb_env:: cpus) starting from lower numbered CPUs looking for the first idle CPU. In hybrid x86 systems, the siblings of SMT cores get CPU numbers, before non-SMT cores: [0, 1] [2, 3] [4, 5] 6 7 8 9 b i b i b i b i i i In the figure above, CPUs in brackets are siblings of an SMT core. The rest are non-SMT cores. 'b' indicates a busy CPU, 'i' indicates an idle CPU. We should let a CPU on a fully idle core get the first chance to idle load balance as it has more CPU capacity than a CPU on an idle SMT CPU with busy sibling. So for the figure above, if we are running should_we_balance() to CPU 1, we should return false to let CPU 7 on idle core to have a chance first to idle load balance. A partially busy (i.e., of type group_has_spare) local group with SMT=C2=A0 cores will often have only one SMT sibling busy.=C2=A0If the destination CPU is a non-SMT core, partially busy, lower-numbered, SMT cores should not be considered when finding the first idle CPU.=C2=A0 However, in should_we_balance(), when we encounter idle SMT first in partia= lly busy core, we prematurely break the search for the first idle CPU. Higher-numbered, non-SMT cores is not given the chance to have idle balance done on their behalf. Those CPUs will only be considered for idle balancing by chance via CPU_NEWLY_IDLE. Instead, consider the idle state of the whole SMT core. Signed-off-by: Ricardo Neri Co-developed-by: Tim Chen Signed-off-by: Tim Chen --- kernel/sched/fair.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index f491b94908bf..294a662c9410 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -10729,7 +10729,7 @@ static int active_load_balance_cpu_stop(void *data); static int should_we_balance(struct lb_env *env) { struct sched_group *sg =3D env->sd->groups; - int cpu; + int cpu, idle_smt =3D -1; =20 /* * Ensure the balancing environment is consistent; can happen @@ -10756,10 +10756,24 @@ static int should_we_balance(struct lb_env *env) if (!idle_cpu(cpu)) continue; =20 + /* + * Don't balance to idle SMT in busy core right away when + * balancing cores, but remember the first idle SMT CPU for + * later consideration. Find CPU on an idle core first. + */ + if (!(env->sd->flags & SD_SHARE_CPUCAPACITY) && !is_core_idle(cpu)) { + if (idle_smt =3D=3D -1) + idle_smt =3D cpu; + continue; + } + /* Are we the first idle CPU? */ return cpu =3D=3D env->dst_cpu; } =20 + if (idle_smt =3D=3D env->dst_cpu) + return true; + /* Are we the first CPU of this group ? */ return group_balance_cpu(sg) =3D=3D env->dst_cpu; } --=20 2.32.0