Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp2342381ybl; Thu, 15 Aug 2019 10:15:07 -0700 (PDT) X-Google-Smtp-Source: APXvYqxMTw3TdY/eae7yLiXPL6mDZjJuXaZvtudeZAA8Ez6pEBijT3Yd6BQE/hy89pNAo30ntkr4 X-Received: by 2002:a65:6546:: with SMTP id a6mr4485748pgw.220.1565889307573; Thu, 15 Aug 2019 10:15:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565889307; cv=none; d=google.com; s=arc-20160816; b=GVS4hNhQOFtc2mSd8Isg6rRmq+74bHz4d6Gg6+hZvyHn9vzgAPVAskmQJdJ6HoNQvx cDFPwDBbYlMSvZsARZBPHRZikY+bYGCZeO2BFJhjEiVGoyJiGlPBjiej2RxTDHXmH1Vy JLyc3IAcU7cgszZd13JiIC5xawDAg3ZRQmV88jcPXYKYvgZjWuCIrM1dyq7+2WePk6yu vf3J32KyoneGyEdL2zDhnimgRJJdvMuioDSn8wrkmzFKnMeLJ/3PBMLLbY9KPEKcVb4c seH7lIuRHj6NG4lGOYpWJf2ChiN8to+9NN6fipZrjF0gAGwkC+50A+HlBoXMSO7fRViG 6gtQ== 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=OmMn1hHSFBisRxAxzxPpXAyo1kuXq7IfCzeHWam5POA=; b=SxHRzUtnTSsirwzKWmvIWyW8KMWzSiAOrD4Rh+IBpke4c4QLYtE6lTRpmLFL6M5rJ5 ALzo0x3eBechgcPEUUtmud6aJssjm9jQ5rlz0+Jau/RdggY2RoLPSu/d6IkOQu3pnM1v ufocokcjUJfkxRkgVnTR0wxuhj2FU24/XBPACk1rZRH5eIbn1jcVRGua/yU+bmQBzf+k gTTaTd8TE28+zjEsBvUQCL1sUYNa1/3Czm/I48EHlBVSUSttQo6mEaHaEbuYxvXvmUW4 xxd7z06dgh2e19LDyHzFjo0WigdR/bGlLwvlfEN6eu+YVWNiygpFV71m6DYXF84q5UD2 LxGg== 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 ck3si2295464plb.429.2019.08.15.10.14.52; Thu, 15 Aug 2019 10:15:07 -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 S1733178AbfHOOwD (ORCPT + 99 others); Thu, 15 Aug 2019 10:52:03 -0400 Received: from foss.arm.com ([217.140.110.172]:45190 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726008AbfHOOwB (ORCPT ); Thu, 15 Aug 2019 10:52:01 -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 15FF2344; Thu, 15 Aug 2019 07:52:01 -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 138523F706; Thu, 15 Aug 2019 07:51:59 -0700 (PDT) From: Valentin Schneider To: linux-kernel@vger.kernel.org Cc: mingo@kernel.org, peterz@infradead.org, vincent.guittot@linaro.org, tglx@linutronix.de, qais.yousef@arm.com Subject: [PATCH v2 4/4] sched/fair: Prevent active LB from preempting higher sched classes Date: Thu, 15 Aug 2019 15:51:07 +0100 Message-Id: <20190815145107.5318-5-valentin.schneider@arm.com> X-Mailer: git-send-email 2.22.0 In-Reply-To: <20190815145107.5318-1-valentin.schneider@arm.com> References: <20190815145107.5318-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 remote rq's 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. This can potentially occur whenever a rq's running task is > CFS but the rq has runnable CFS tasks. Check the sched class of the remote rq's running task after we've grabbed its lock. If it's CFS, carry on, otherwise run detach_one_task() locally since we don't need the cpu_stopper (that !CFS task is doing the exact same thing). Signed-off-by: Valentin Schneider --- kernel/sched/fair.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 8f5f6cad5008..bf4f7f43252f 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -8759,6 +8759,7 @@ static inline enum alb_status active_load_balance(struct lb_env *env) enum alb_status status = cancelled; struct sched_domain *sd = env->sd; struct rq *busiest = env->src_rq; + struct task_struct *p = NULL; unsigned long flags; schedstat_inc(sd->lb_failed[env->idle]); @@ -8780,6 +8781,16 @@ static inline enum alb_status active_load_balance(struct lb_env *env) if (busiest->cfs.h_nr_running < 1) goto unlock; + /* + * If busiest->curr isn't CFS, then there's no point in running the + * cpu_stopper. We can try to nab one CFS task though, since they're + * all ready to be plucked. + */ + if (busiest->curr->sched_class != &fair_sched_class) { + p = detach_one_task(env); + 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: @@ -8803,7 +8814,9 @@ static inline enum alb_status active_load_balance(struct lb_env *env) unlock: raw_spin_unlock_irqrestore(&busiest->lock, flags); - if (status == started) + if (p) + attach_one_task(env->dst_rq, p); + else if (status == started) stop_one_cpu_nowait(cpu_of(busiest), active_load_balance_cpu_stop, busiest, &busiest->active_balance_work); -- 2.22.0