Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp71107rwl; Thu, 6 Apr 2023 13:22:06 -0700 (PDT) X-Google-Smtp-Source: AKy350YDzlhU+1iJlbV2Az+hzCAcgLNLZcZXVjeV86kKdEs5r8b8n499Ad7Fj3bn5MeRF6wo+H0p X-Received: by 2002:a50:fb87:0:b0:501:d532:d84e with SMTP id e7-20020a50fb87000000b00501d532d84emr550841edq.39.1680812526108; Thu, 06 Apr 2023 13:22:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680812526; cv=none; d=google.com; s=arc-20160816; b=r0inMSp6+Y5tPnKIws7+dTRPOU+ABcgrXW/thjTqQsTLCA+Zrkm43Dii1AP+VbsTsq MyAjcWUgmhfFlM7ZlN12mgI4y6rAozJt4d+S6hXvwJ/BKfTFhruvYTmlXcq4z+DkIVSB GTfYLZ1MOZB8hvZ2nRVDF67yQ/pV1IgPI7xqbYzZAn9KQ8zMhfNvnyqBEhgL+OIl6xNm Oewvynzf3XzRr9rmnmEI1qnv1EK2DbICERoPGMCV8Ot5eRJowrUfCZ2D01DNpwZ+Sx92 W15dAJ3LedlVKrJT0t2/YpKF0sC/KWzuoozfjZoh1hr9C9dV8ESg8z3UvklO2jeixzi8 RuZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:references:in-reply-to:message-id:date:subject :cc:to:from:dkim-signature; bh=Xf1tQ34+OGj/ScKGrOqLFmbFzP/sU6EFm6HKhaz5Sgw=; b=dhEdqqa38gVQejfimOkuOURNEzG1oatBSvAv9Vd5J1mgMGopaSN+alk1eDA/H6iila 7dDHBxxPEsPHSAKGl5uCKz/xCjxFem+fxV0/27SYWi7SuAm4SxjaaWPw6AE1ypvExpuW 5OYN40YcVP2V/QUH5yK+2DDc4YUMY5zLtbUbwCkDdc0eIaSWGyIFjwzA9ISmJg+nkyU2 0+31XVw93olGYk7OkJhATJVm/Awv+ePTpOw/2IKl8sU0wKobfj0yXBOa1MjbKswOPaZc upLMeJJUO3x1XTULg/8a5+aOhJeARB5p/JC++BQVE2H8CUjJXdm4lTdkF6vWvEG6rAGV MXeg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=Pwwu+MM5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q3-20020a056402032300b005042f9269e8si777625edw.100.2023.04.06.13.21.28; Thu, 06 Apr 2023 13:22:06 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=Pwwu+MM5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239042AbjDFUVK (ORCPT + 99 others); Thu, 6 Apr 2023 16:21:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55094 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238914AbjDFUVB (ORCPT ); Thu, 6 Apr 2023 16:21:01 -0400 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 35A7D7290 for ; Thu, 6 Apr 2023 13:21:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1680812460; x=1712348460; h=from:to:cc:subject:date:message-id:in-reply-to: references; bh=T7YcPvoqJl/ysW/iYHGXA37dyyCN2NzIcKZ5yP9G8sU=; b=Pwwu+MM57QSWnnkKuzR7wqcvhgM1pSQnPweIv3w0PiD+rlmYmnQKnX2R O9mOAEpSzKQRQEsUiA6lDlXMde2KXQIrYx/JIQjuN3zr6XLBaj8Q10iqz 1yomnnF0AQdFRzxNuRiEyZqE0xifMuO3EN5prc5KYI2/qvvgCpol8zep/ mdJVUB056L+FN/pL9iSZR7IIGe4bR/vqjo6iqe1vOOsdKBzP1JDbptsn0 F/X4Ir0Mtxv2RufhkqZolAUFb04T++QBoc7nzIlIUJHCJiurCCnpTJ5xp lEeObK5iKiTf4b/+baCBg0RLkzu3BbijgiOm/y2O4kGn32BvvHTH5IFQY g==; X-IronPort-AV: E=McAfee;i="6600,9927,10672"; a="407957718" X-IronPort-AV: E=Sophos;i="5.98,323,1673942400"; d="scan'208";a="407957718" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Apr 2023 13:20:58 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10672"; a="861529872" X-IronPort-AV: E=Sophos;i="5.98,323,1673942400"; d="scan'208";a="861529872" Received: from ranerica-svr.sc.intel.com ([172.25.110.23]) by orsmga005.jf.intel.com with ESMTP; 06 Apr 2023 13:20:58 -0700 From: Ricardo Neri To: "Peter Zijlstra (Intel)" , Juri Lelli , Vincent Guittot Cc: 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, Ricardo Neri , "Tim C . Chen" Subject: [PATCH v4 03/12] sched/fair: Simplify asym_packing logic for SMT cores Date: Thu, 6 Apr 2023 13:31:39 -0700 Message-Id: <20230406203148.19182-4-ricardo.neri-calderon@linux.intel.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20230406203148.19182-1-ricardo.neri-calderon@linux.intel.com> References: <20230406203148.19182-1-ricardo.neri-calderon@linux.intel.com> X-Spam-Status: No, score=-2.4 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H2, SPF_HELO_NONE,SPF_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Callers of asym_smt_can_pull_tasks() check the idle state of the destination CPU and its SMT siblings, if any. No extra checks are needed in such function. Since SMT cores divide capacity among its siblings, priorities only really make sense if only one sibling is active. This is true for SMT2, SMT4, SMT8, etc. Do not use asym_packing load balance for this case. Instead, let find_busiest_group() handle imbalances. When balancing non-SMT cores or at higher scheduling domains (e.g., between MC scheduling groups), continue using priorities. Cc: Ben Segall Cc: Daniel Bristot de Oliveira Cc: Dietmar Eggemann Cc: Ionela Voinescu Cc: Len Brown Cc: Mel Gorman Cc: Rafael J. Wysocki Cc: Srinivas Pandruvada Cc: Steven Rostedt Cc: Tim C. Chen Cc: Valentin Schneider Cc: x86@kernel.org Cc: linux-kernel@vger.kernel.org Tested-by: Zhang Rui Reviewed-by: Len Brown Signed-off-by: Ricardo Neri --- Changes since v3: * Dropped checks for a destination SMT core. * Limited the check of a single busy CPU to SMT cores. This fixes a bug when balancing between MC scheduling groups of different priority. Changes since v2: * Updated documentation of the function to reflect the new behavior. (Dietmar) Changes since v1: * Reworded commit message and inline comments for clarity. * Stated that this changeset does not impact SMT4 or SMT8. --- kernel/sched/fair.c | 33 ++++++++++++--------------------- 1 file changed, 12 insertions(+), 21 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index ec7ddbfd1136..b6bbe0300635 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -9313,12 +9313,9 @@ static bool sched_use_asym_prio(struct sched_domain *sd, int cpu) * the SMT siblings of @sg are busy. If only one CPU in @sg is busy, pull tasks * only if @dst_cpu has higher priority. * - * If both @dst_cpu and @sg have SMT siblings, and @sg has exactly one more - * busy CPU than @sds::local, let @dst_cpu pull tasks if it has higher priority. - * Bigger imbalances in the number of busy CPUs will be dealt with in - * update_sd_pick_busiest(). - * - * If @sg does not have SMT siblings, only pull tasks if @sg has lower priority. + * When dealing with SMT cores, only use priorities if the SMT core has exactly + * one busy sibling. find_busiest_group() will handle bigger imbalances in the + * number of busy CPUs. * * Return: true if @dst_cpu can pull tasks, false otherwise. */ @@ -9327,12 +9324,10 @@ static bool asym_smt_can_pull_tasks(int dst_cpu, struct sd_lb_stats *sds, struct sched_group *sg) { #ifdef CONFIG_SCHED_SMT - bool local_is_smt, sg_is_smt; + bool local_is_smt; int sg_busy_cpus; local_is_smt = sds->local->flags & SD_SHARE_CPUCAPACITY; - sg_is_smt = sg->flags & SD_SHARE_CPUCAPACITY; - sg_busy_cpus = sgs->group_weight - sgs->idle_cpus; if (!local_is_smt) { @@ -9353,21 +9348,17 @@ static bool asym_smt_can_pull_tasks(int dst_cpu, struct sd_lb_stats *sds, return sched_asym_prefer(dst_cpu, sg->asym_prefer_cpu); } - /* @dst_cpu has SMT siblings. */ - - if (sg_is_smt) { - int local_busy_cpus = sds->local->group_weight - - sds->local_stat.idle_cpus; - int busy_cpus_delta = sg_busy_cpus - local_busy_cpus; - - if (busy_cpus_delta == 1) - return sched_asym_prefer(dst_cpu, sg->asym_prefer_cpu); - + /* + * If we are here @dst_cpu has SMT siblings and are also idle. + * + * CPU priorities does not make sense for SMT cores with more than one + * busy sibling. + */ + if (group->flags & SD_SHARE_CPUCAPACITY && sg_busy_cpus != 1) return false; - } - /* If we are here @dst_cpu has SMT siblings and are also idle. */ return sched_asym_prefer(dst_cpu, sg->asym_prefer_cpu); + #else /* Always return false so that callers deal with non-SMT cases. */ return false; -- 2.25.1