From mboxrd@z Thu Jan 1 00:00:00 1970 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 E5FBFC7EE21 for ; Thu, 4 May 2023 16:11:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229659AbjEDQLu (ORCPT ); Thu, 4 May 2023 12:11:50 -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 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