Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1220790pxb; Thu, 28 Jan 2021 10:44:11 -0800 (PST) X-Google-Smtp-Source: ABdhPJzOfUbN4Vq/qSED0wqLs+2djLFHHnoi/+wixPOufnwTMxY7bHU8AnfbTuaMVRAzDNN6TSqR X-Received: by 2002:a17:906:9381:: with SMTP id l1mr780237ejx.433.1611859450856; Thu, 28 Jan 2021 10:44:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611859450; cv=none; d=google.com; s=arc-20160816; b=X/DHALmsbuVM9R69IvA3td3FH15Ji6unVWH0qEmNkiUa0qRCt7WNxenRIu0V2z4dsP Ex9Tsppb0BpUW2GL0Uz86e5w8mUJuiTku3ctLUPVNlxB/QnHlP1kAs0XSWpQ+Kby3Q8k hnjh8LzY7i1Ri7Y7nb7LznH+5rc4bMfWTg8JssPi5a50/03l32gJ0sscTYuh0z4slzMi 0Tx43Wsa1VGfFLoUftZT8nHM0ZE+7VZ5J0N2y+02xsCpfFoWfgEQAu0wIoIsZqaloqG0 VE4SqO304QlBIRI72+mT+SM57cXuy0dlbHKRLlzFJCFOWrCJcCms/wOi9QjQRkmlcQ7a ULaw== 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; bh=R0sPlrzxRZM4kG2Syf8ijnAZFD+B2j5VO1EMlabHIbg=; b=iS6ozSNF4cs37X1tUjvDM6y2AoYE2Z7AeZXMjxCl4SCBommJbLTZc4Z/7rDRzIn1Jf yPpfp06uSSdgmmujqPH8Kr9okIc1GhBpnC+dWoccEqbnnI3Mkk2ttbIVbcfhVtjNlZQb I6ejv/w+SarNZd/JRy8J2urUTPPU67MSUT+QVYMJzo/czT+bfmrj/CGtw/m77lr15/4q WdWGF7Pz0UXQ4wwft+oe1aUmUHCmPbQ4FJfkgeMpI9Ip2Yu5DUqnMXz3L+oRg+k1rfiH eZa6ifp1sW1ouy2GYjj7Uo9yD/QRMBZs6btWQE/4scocOjviLg9wogrQ8Z0H5BUjhlyo wo0w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id yr3si3231478ejb.153.2021.01.28.10.43.45; Thu, 28 Jan 2021 10:44:10 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232201AbhA1Skv (ORCPT + 99 others); Thu, 28 Jan 2021 13:40:51 -0500 Received: from foss.arm.com ([217.140.110.172]:37446 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232151AbhA1SfI (ORCPT ); Thu, 28 Jan 2021 13:35:08 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 6D11814FF; Thu, 28 Jan 2021 10:32:17 -0800 (PST) Received: from e113632-lin.cambridge.arm.com (e113632-lin.cambridge.arm.com [10.1.194.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id F37533F719; Thu, 28 Jan 2021 10:32:15 -0800 (PST) From: Valentin Schneider To: linux-kernel@vger.kernel.org Cc: Peter Zijlstra , Ingo Molnar , Vincent Guittot , Dietmar Eggemann , Morten Rasmussen , Qais Yousef , Quentin Perret , Pavan Kondeti , Rik van Riel Subject: [PATCH 7/8] sched/fair: Attempt misfit active balance when migration_type != migrate_misfit Date: Thu, 28 Jan 2021 18:31:40 +0000 Message-Id: <20210128183141.28097-8-valentin.schneider@arm.com> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20210128183141.28097-1-valentin.schneider@arm.com> References: <20210128183141.28097-1-valentin.schneider@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Consider a 4-CPU big.LITTLE system with CPUs 0-1 as LITTLEs and CPUs 2-3 as bigs. The resulting sched_domain hierarchy is: DIE [ ] MC [ ][ ] 0 1 2 3 When running a multithreaded CPU-bound workload (i.e. 1 hog per CPU), the expected behaviour is to have the about-to-idle big CPUs pull a hog from the LITTLEs, since bigs will complete their work sooner than LITTLEs. Further Consider a scenario where: - CPU0 is idle (e.g. its hog got migrated to one of the big CPUs) - CPU1 is currently executing a per-CPU kworker, preempting the CPU hog - CPU2 and CPU3 are executing CPU-hogs CPU0 goes through load_balance() at MC level, and tries to pick stuff from CPU1, but: - the hog can't be pulled, because it's task_hot() - the kworker can't be pulled, because it's pinned to CPU1, which sets LBF_SOME_PINNED This load balance attempts ends with no load pulled, LBF_SOME_PINNED set, and as a consequence we set the imbalance flag of DIE's [0, 1] sched_group_capacity. Shortly after, CPU2 completes its work and is about to go idle. It goes through the newidle_balance(), and we would really like it to active balance the hog running on CPU1 (which is a misfit task). However, sgc->imbalance is set for the LITTLE group at DIE level, so the group gets classified as group_imbalanced rather than group_misfit_task. Unlike group_misfit_task (via migrate_misfit), the active balance logic doesn't have any specific case for group_imbalanced, so CPU2 ends up going idle. We'll have to wait for a load balance on CPU0 or CPU1 to happen and clear the imbalance flag, and then for another DIE-level load-balance on CPU2 to happen to pull the task off of CPU1. That's several precious milliseconds wasted down the drain. Giving group_misfit_task a higher group_classify() priority than group_imbalance doesn't seem like the right thing to do. Instead, make need_active_balance() return true for any migration_type when the destination CPU is idle and the source CPU has a misfit task. While at it, add an sd_has_asym_cpucapacity() guard in need_active_balance(). Signed-off-by: Valentin Schneider --- kernel/sched/fair.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 0ac2f876b86f..cba9f97d9beb 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -9557,9 +9557,22 @@ static int need_active_balance(struct lb_env *env) return 1; } + if (!sd_has_asym_cpucapacity(sd)) + return 0; + if (env->migration_type == migrate_misfit) return 1; + /* + * If we failed to pull anything and the src_rq has a misfit task, but + * the busiest group_type was higher than group_misfit_task, try to + * go for a misfit active balance anyway. + */ + if ((env->idle != CPU_NOT_IDLE) && + env->src_rq->misfit_task_load && + cpu_capacity_greater(env->dst_cpu, env->src_cpu)) + return 1; + return 0; } -- 2.27.0