Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp6390364rwb; Tue, 22 Nov 2022 12:40:42 -0800 (PST) X-Google-Smtp-Source: AA0mqf57HbnwhXOYfuavB7n0ho3l5y4MOYnvPhpJf8RMROuWIUGrMYoWZc3uDwgoW7HCeHzA0oi6 X-Received: by 2002:a63:220c:0:b0:46a:e819:216c with SMTP id i12-20020a63220c000000b0046ae819216cmr11510434pgi.155.1669149642131; Tue, 22 Nov 2022 12:40:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669149642; cv=none; d=google.com; s=arc-20160816; b=IdEotxA8f6kuRLjykuCl/IXvWvDDM8bQng7ac/nvgCwu62fpYJ9Gusg10bpR3vMHjk ECbJQFgEAOcurm0q3zN2clhyNzxpW4BfsyvgkRXOIRbs0BXJx7K3Q41jcgTkibmmyKQ+ tvGbbm+ugexUvhe3AH84zei+axdAKokgbix5dG+Eww3MM3SyPvKgNSAyNzms8/v0g52Y XgM0Lx/yeYDToddDMFR8BqovFttPTapmdO86H1J0X3XYZmVuwwKnRc0e/SffVlD8LNpx 30pwPmiTerCVmF3kMNvJSBR49K+8nD/xVqpZK8AxuRTO0Zi/KSvwkrpIjqZ1lvNdrAD8 By6g== 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=0FmmaYWUUzyBYDYSIO8jz1OqA5s3Tbt6NxESnfIcMjM=; b=YfoFjaHNn+xkgiR1YydKRuaVI660h/7lJ27FgtOcZWKDV7SXuwtM3fHop598OvIP6w tdpxyo2NDHOooxlDIGyfGj9+qq3vRVUtUBJ6gH5ZXwMULEofQ7JaehuQDqcOxPQLpOCL GRPxJipKPmC/lYHe64nt7ncO+u9Gc9lnxECvHyQd7q4pJYUJGnWOG6lgM989+3J0A4GY jaRRkvN/Mahcb+GefsJ4j7yfL/G4TzVfkLLSkPVaFiRaJtPhNgf5iejz5VZ0KbptCnpp 6YVswf+g8E6MIypOCbC6hqyXw6hzH0GskJVw+wRFXz4iwHVmrm87mLG/FVkaLecr4qrr ZuVQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=VixAVveT; 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 x24-20020a63db58000000b0046fe64444fcsi14261578pgi.839.2022.11.22.12.40.30; Tue, 22 Nov 2022 12:40:42 -0800 (PST) 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=VixAVveT; 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 S234791AbiKVU2Z (ORCPT + 89 others); Tue, 22 Nov 2022 15:28:25 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37968 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232554AbiKVU2O (ORCPT ); Tue, 22 Nov 2022 15:28:14 -0500 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E11EE1AD83 for ; Tue, 22 Nov 2022 12:28:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1669148893; x=1700684893; h=from:to:cc:subject:date:message-id:in-reply-to: references; bh=0yHmKdRsV591tHGMnKRYVefaIOCtc6d0I/pJdG+LlvU=; b=VixAVveTTgBILU537x5lOBygOGbEtNITiTtO12/uMiymItMal26+/PfT EWaE9taAOryiZQ6bDPqaWr3nfsCf0VphmrraexHIxFL8sTO/zJld679p9 g+BtA8xRQgcjsCVwlYe5hV/mBO56OETLCkqBk3XEIvP81yfF7wt5Z7WNG 4B7c3G1gLvUn9oT0eIuM7Ai8jn4qPUVeJoOhz7pXI5HjeiHiRbq6lW7VZ OcLRgnPwvKooEJTPH1hpsI2JW6MGrIgGRQLxgRexjNnc954PMgPISKr+B abdROcQZJWxzIgBvFXP66hfbPPHvYVOS91j28vHgdmyQjzgT8TcHZL+LG Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10539"; a="293616500" X-IronPort-AV: E=Sophos;i="5.96,185,1665471600"; d="scan'208";a="293616500" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Nov 2022 12:28:12 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10539"; a="816228121" X-IronPort-AV: E=Sophos;i="5.96,185,1665471600"; d="scan'208";a="816228121" Received: from ranerica-svr.sc.intel.com ([172.25.110.23]) by orsmga005.jf.intel.com with ESMTP; 22 Nov 2022 12:28:12 -0800 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 , x86@kernel.org, linux-kernel@vger.kernel.org, Ricardo Neri , "Tim C . Chen" Subject: [PATCH v2 1/7] sched/fair: Generalize asym_packing logic for SMT local sched group Date: Tue, 22 Nov 2022 12:35:26 -0800 Message-Id: <20221122203532.15013-2-ricardo.neri-calderon@linux.intel.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20221122203532.15013-1-ricardo.neri-calderon@linux.intel.com> References: <20221122203532.15013-1-ricardo.neri-calderon@linux.intel.com> X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_PASS, SPF_NONE autolearn=ham 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 When balancing load between two physical cores, an idle destination CPU can help another core only if all of its SMT siblings are also idle. Otherwise, there is not increase in throughput. It does not matter whether the other core is composed of SMT siblings. Simply check if there are any tasks running on the local group and the other core has exactly one busy CPU before proceeding. Let find_busiest_group() handle the case of more than one busy CPU. This is true for SMT2, SMT4, SMT8, etc. Cc: Ben Segall Cc: Daniel Bristot de Oliveira Cc: Dietmar Eggemann 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 Reviewed-by: Len Brown Signed-off-by: Ricardo Neri --- Changes since v1: * Reworded commit message and inline comments for clarity. * Stated that this changeset does not impact STM4 or SMT8. --- kernel/sched/fair.c | 29 +++++++++-------------------- 1 file changed, 9 insertions(+), 20 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index e4a0b8bd941c..18c672ff39ef 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -8900,12 +8900,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) { @@ -8926,25 +8924,16 @@ 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); - - return false; - } - /* - * @sg does not have SMT siblings. Ensure that @sds::local does not end - * up with more than one busy SMT sibling and only pull tasks if there - * are not busy CPUs (i.e., no CPU has running tasks). + * @dst_cpu has SMT siblings. Do asym_packing load balancing only if + * all its siblings are idle (moving tasks between physical cores in + * which some SMT siblings are busy results in the same throughput). + * + * If the difference in the number of busy CPUs is two or more, let + * find_busiest_group() take care of it. We only care if @sg has + * exactly one busy CPU. This covers SMT and non-SMT sched groups. */ - if (!sds->local_stat.sum_nr_running) + if (sg_busy_cpus == 1 && !sds->local_stat.sum_nr_running) return sched_asym_prefer(dst_cpu, sg->asym_prefer_cpu); return false; -- 2.25.1