Received: by 2002:a25:b794:0:0:0:0:0 with SMTP id n20csp5753311ybh; Wed, 7 Aug 2019 10:49:52 -0700 (PDT) X-Google-Smtp-Source: APXvYqyUIIisH/3P4C05AmynY0jV14pNDfzT5TXMIJzyEVPvPbLyqZ5MGQutIh1Xji7Vc2uisbSs X-Received: by 2002:a63:b102:: with SMTP id r2mr8588347pgf.370.1565200192402; Wed, 07 Aug 2019 10:49:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565200192; cv=none; d=google.com; s=arc-20160816; b=W83HgZ4U5AW48m5YwLVu6MCcMoMbUIH5QCPE/sLH1hSlBLfpjx+iruuug4ElR7DmRp YBMmsjz9CZ1NaAOZOtNwD7/G97LIB4TIT95vEyJvGYMN9wlKhDArc4OXK8GiNRMLVv2R pIAkRDt4EDnK+mG/wX+IXA4+9TPW7ba30IhJMLZXct7BrREShU+qVwz9ujDMeohNrM9O U0KVSHQ+CcOpSbdSuW7YiLafGLHyJ/TCKPnjDdsHc6bguoTiRwbZjCEfdE3yvuvHDK/O 4+h+hs1RQN4sJ7VEoXWV0JFMgSFIk7VJpxZlO+Jr3GZ8xgtKKCi/jxYGN8zK9BgpaBDz yPpw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=4XsxZ7b+ivn2lrVMjxzOFsKVuOry/izQXwf3sCCygSc=; b=0uyJ9Qf2dtQHBA7P3Glq641XeX0effneMbItTBuzj23aCj6cjAcYq8qz3De4LwiVqz W2FphvXrKwELyzXUGsbuqaY6hrFrlCHAlO8b1HpMHTNkIydAjuSVRQY5Pj/M5tH9c9yH CS+6wYY1U49ZbzWkLsXudJdPQQe49URGWZosA8D8LPSldJO3DhasRsW9LSWXvLthKqr6 565vSl4t6/okha4g6JrKjIgWxfAEUswGWE2qz/7RcFkAkp48dXkrdD77El5H2f07bOX2 0uoW2UCpnSU6/ZsHX7Dre3pIeqfeTWQoZ2uOybuDLFDIQ7geF0alhXXX3Dc7DT1d3uyq 0sOg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 28si15374839pgn.250.2019.08.07.10.49.37; Wed, 07 Aug 2019 10:49:52 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389222AbfHGRlS (ORCPT + 99 others); Wed, 7 Aug 2019 13:41:18 -0400 Received: from foss.arm.com ([217.140.110.172]:52528 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388369AbfHGRlP (ORCPT ); Wed, 7 Aug 2019 13:41:15 -0400 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 DC26115A2; Wed, 7 Aug 2019 10:41:14 -0700 (PDT) Received: from e113632-lin.cambridge.arm.com (e113632-lin.cambridge.arm.com [10.1.194.37]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 1BC853F575; Wed, 7 Aug 2019 10:41:14 -0700 (PDT) From: Valentin Schneider To: linux-kernel@vger.kernel.org Cc: mingo@kernel.org, peterz@infradead.org, vincent.guittot@linaro.org Subject: [PATCH 2/3] sched/fair: Prevent active LB from preempting higher sched classes Date: Wed, 7 Aug 2019 18:40:25 +0100 Message-Id: <20190807174026.31242-3-valentin.schneider@arm.com> X-Mailer: git-send-email 2.22.0 In-Reply-To: <20190807174026.31242-1-valentin.schneider@arm.com> References: <20190807174026.31242-1-valentin.schneider@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The CFS load balancer can cause the cpu_stopper to run a function to try and steal a rq's currently running task. However, it so happens that while only CFS tasks will ever be migrated by that function, we can end up preempting higher sched class tasks, since it is executed by the cpu_stopper. I don't expect this to be exceedingly common: we still need to have had a busiest group in the first place, which needs busiest->sum_nr_running != 0 which is a cfs.h_nr_running sum, so we should have something to pull, but if we fail to pull anything and the remote rq is executing an RT/DL task we can hit this. Add an extra check to not trigger the cpu_stopper if the remote rq's running task isn't CFS. Signed-off-by: Valentin Schneider --- kernel/sched/fair.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index b56b8edee3d3..79bd6ead589c 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -8834,6 +8834,10 @@ static inline enum alb_status active_load_balance(struct lb_env *env) raw_spin_lock_irqsave(&busiest->lock, flags); + /* Make sure we're not about to stop a task from a higher sched class */ + if (busiest->curr->sched_class != &fair_sched_class) + goto unlock; + /* * Don't kick the active_load_balance_cpu_stop, if the curr task on * busiest CPU can't be moved to dst_cpu: -- 2.22.0