Received: by 2002:a05:6358:9144:b0:117:f937:c515 with SMTP id r4csp799983rwr; Thu, 4 May 2023 09:42:00 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4Za4+ocyq9pfAe4rEkq2ELgj3lUmceYSIvv8JQUeDgj3rqWCLN9P1YJQixsPYrBIt3meqp X-Received: by 2002:a17:90b:3a87:b0:247:a53e:97a1 with SMTP id om7-20020a17090b3a8700b00247a53e97a1mr2790933pjb.28.1683218520232; Thu, 04 May 2023 09:42:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1683218520; cv=none; d=google.com; s=arc-20160816; b=uKdk7RxL/TAwf6O4phnees8giwe2Tdz9K7t7htFvDRoDzQzw0sbj71SzT/1hNwndDs XUNkoDA3TQDWJ110vHeqLCbFB8wT4k8aKt3yUBE973QLntG2IX3uLGSC+ENhOeGGXvr5 NBKee75hNVtk7u6GWWVmt43CGCHnzaINz1aqgDGfEQdoj50XCWIXsuAx8zn0x/SWlCkl mCLHresB7qwjvRsNwMfz5AdZrnDt+dfIYyePl4wisDFbWeFNP6LEAEPkEIOoAtWrXQsL xno99B+tLiN25ct1+SLcbDGzEdsZ2yRRmvLV3P1hTTrKefCyKU6sb8SuHc5ccquI4en0 wvLQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=g0Ek977lxiNsOy+Ifw91Utn/qrO6LEO3lb6ODDZ1aPs=; b=PvUz9XyVnqBRkzR+vjY68Bj+Iq78L7j8avyBfkoIwdYqeoIvYTUkmjCLbJCi0kzO3P 4eUeJ0Bmvdixu6aYWGveAf88DXyJ8/IE/9JjwCBg7jDZSLKGzmDXp6HkwpvOsjhRRYSt hX7lRByoy4HtiBrcFV79Hz3BP7//nN6B8enYTbeMUrg9Rt0eqbzEIaI3LCIBbMII8Rvi Z1kMhwQJi9NqDeqGu9hPaTk4kJ/9tMUZAyUSMr1l/Uv/BKwkabdQw8aP3V/6vSkwXspf Njhuf2bydyqhddVOHQLE9/xAgRy0/v9lOp4rndCd1k1ciNcFf5hIJBOCNAUZtW68raU4 LTMw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="huA/9Z3t"; 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 em13-20020a17090b014d00b0023a177c4951si6377559pjb.39.2023.05.04.09.41.47; Thu, 04 May 2023 09:42:00 -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="huA/9Z3t"; 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 S229651AbjEDQLt (ORCPT + 99 others); Thu, 4 May 2023 12:11:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39438 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229598AbjEDQLo (ORCPT ); Thu, 4 May 2023 12:11:44 -0400 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 129655BA0 for ; Thu, 4 May 2023 09:11:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1683216703; x=1714752703; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=EFWPb4ErsWepqS9IbJJhFL7X3JBr0JI87KPptB5lfEU=; b=huA/9Z3tzI/RWDegC/CErzjjCExCt/7xHb9Pz7+53dzoVHgv+5MtRXKR lpkZjB9T7vgQTqI+CD5kS7NhuP1w1XFB0hR8NftHa3nYhx/75wZqqEr3h fIVckMtTiNEZ0HuA2u+NAY+K68Us0bHfuEiyjom2bEwH4qcmMyqcX1GaO WPi0BKIO5kUcJ5kHWANFThrWYa9H+Jl1DE1fx8et19S0oFTf0sq+3PO6w Bh7W/mPZMKZV7TwNPukIpHLHpkOLKshMK2I6+qF8JTuD3SzNT9qPiZXb2 GFtqC9hXlRyz7AX93f7Nl8YRFlE8d/FZ/1ml5JDY/a3UoHSCDrxL8WyfT Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10700"; a="377049065" X-IronPort-AV: E=Sophos;i="5.99,249,1677571200"; d="scan'208";a="377049065" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 May 2023 09:09:33 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10700"; a="766633528" X-IronPort-AV: E=Sophos;i="5.99,249,1677571200"; d="scan'208";a="766633528" Received: from b04f130c83f2.jf.intel.com ([10.165.154.98]) by fmsmga004.fm.intel.com with ESMTP; 04 May 2023 09:09:32 -0700 From: Tim Chen To: Peter Zijlstra Cc: Tim C Chen , 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 , 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 , Ricardo Neri Subject: [PATCH 3/6] sched/fair: Fix busiest group selection for asym groups Date: Thu, 4 May 2023 09:09:53 -0700 Message-Id: <2e2e6844fb3ed28594d86c5e45295df7c4335c08.1683156492.git.tim.c.chen@linux.intel.com> X-Mailer: git-send-email 2.32.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED 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 From: Tim C Chen For two groups that have spare capacity and are partially busy, the busier group should be the group with pure CPUs rather than the group with SMT CPUs. We do not want to make the SMT group the busiest one to pull task off the SMT and makes the whole core empty. Otherwise suppose in the search for busiest group, we first encounter an SMT group with 1 task and set it as the busiest. The local group is an atom cluster with 1 task and we then encounter an atom cluster group with 3 tasks, we will not pick this atom cluster group over the SMT group, even though we should. As a result, we do not load balance the busier Atom cluster (with 3 tasks) towards the local Atom cluster (with 1 task). And it doesn't make sense to pick the 1 task SMT group as the busier group as we also should not pull task off the SMT towards the 1 task atom cluster and make the SMT core completely empty. Fix this case. Reviewed-by: Ricardo Neri Signed-off-by: Tim Chen --- kernel/sched/fair.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index bde962aa160a..8a325db34b02 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -9548,6 +9548,18 @@ static bool update_sd_pick_busiest(struct lb_env *env, break; case group_has_spare: + /* + * Do not pick sg with SMT CPUs over sg with pure CPUs, + * as we do not want to pull task off half empty SMT core + * and make the core idle. + */ + if (asymmetric_groups(sds->busiest, sg)) { + if (sds->busiest->flags & SD_SHARE_CPUCAPACITY) + return true; + else + return false; + } + /* * Select not overloaded group with lowest number of idle cpus * and highest number of running tasks. We could also compare -- 2.32.0