From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758155AbdELRCX (ORCPT ); Fri, 12 May 2017 13:02:23 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:43628 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757932AbdELRCV (ORCPT ); Fri, 12 May 2017 13:02:21 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 48B476021C Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=jhugo@codeaurora.org From: Jeffrey Hugo To: Ingo Molnar , Peter Zijlstra , linux-kernel@vger.kernel.org Cc: Dietmar Eggemann , Austin Christ , Tyler Baicar , Jeffrey Hugo Subject: [RFC 1/2] sched/fair: Fix load_balance() affinity redo path Date: Fri, 12 May 2017 11:01:37 -0600 Message-Id: <1494608498-4538-2-git-send-email-jhugo@codeaurora.org> X-Mailer: git-send-email 1.8.5.2 In-Reply-To: <1494608498-4538-1-git-send-email-jhugo@codeaurora.org> References: <1494608498-4538-1-git-send-email-jhugo@codeaurora.org> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org If load_balance() fails to migrate any tasks because all tasks were affined, load_balance() removes the source cpu from consideration and attempts to redo and balance among the new subset of cpus. There is a bug in this code path where the algorithm considers all active cpus in the system (minus the source that was just masked out). This is not valid for two reasons: some active cpus may not be in the current scheduling domain and one of the active cpus is dst_cpu. These cpus should not be considered, as we cannot pull load from them. Instead of failing out of load_balance(), we may end up redoing the search with no valid cpus and incorrectly concluding the domain is balanced. Additionally, if the group_imbalance flag was just set, it may also be incorrectly unset, thus the flag will not be seen by other cpus in future load_balance() runs as that algorithm intends. Fix the check by removing cpus not in the current domain and the dst_cpu from considertation, thus limiting the evaluation to valid remaining cpus from which load might be migrated. Signed-off-by: Austin Christ Signed-off-by: Dietmar Eggemann Signed-off-by: Jeffrey Hugo Tested-by: Tyler Baicar --- kernel/sched/fair.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index d711093..8f783ba 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -8219,8 +8219,19 @@ static int load_balance(int this_cpu, struct rq *this_rq, /* All tasks on this runqueue were pinned by CPU affinity */ if (unlikely(env.flags & LBF_ALL_PINNED)) { + struct cpumask tmp; + + /* Cpumask of all initially possible busiest cpus. */ + cpumask_copy(&tmp, sched_domain_span(env.sd)); + cpumask_clear_cpu(env.dst_cpu, &tmp); + cpumask_clear_cpu(cpu_of(busiest), cpus); - if (!cpumask_empty(cpus)) { + /* + * Go back to "redo" iff the load-balance cpumask + * contains other potential busiest cpus for the + * current sched domain. + */ + if (cpumask_intersects(cpus, &tmp)) { env.loop = 0; env.loop_break = sched_nr_migrate_break; goto redo; -- Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.