Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp7075185ybf; Fri, 6 Mar 2020 09:53:11 -0800 (PST) X-Google-Smtp-Source: ADFU+vt3izRDNLabSTn2soO6rKzyKabxxeEdq1hc273GTrn7u9f/cflheFv5Kc8LiH6DgDMNV9i6 X-Received: by 2002:aca:f354:: with SMTP id r81mr3352466oih.90.1583517191439; Fri, 06 Mar 2020 09:53:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583517191; cv=none; d=google.com; s=arc-20160816; b=Ou98qpK3Vi+5OSkGEQXWEOU3NkcyJv0Ju6DyZ6TH8V5xlgMbiqpf1hv8cwVV15JeXu 2Tpnr9QIn14ooFcimQK7PXYQD7Z9YAA3cfzTxUT9UNOxsht8jAE+UY9hMbk8dcHAmxNJ 1pXOTyNhEY72HpnPUoyFZzicATKZrlBcCWALZktYUuImpu7odScquk96+uKsH1atmaso KxxiOYDXh4lH5PSGsLT82EJNP5jzc7BNxYTyiG5KCZIn/Tzx3cVDXoWZ61zR0zanisYv w1VrZqHNe+Kd+98nUW/v/70iYrynkZ7iE932QwV5R98b0obQHcpeIhKQnXOhg6DDax7C R7PQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=Y+D1reVVgUbxp0uGzCQfYYa9UqsiUDE357epS4QHd2M=; b=X05RBbPasPcy+3R1p5tTkJB4Fq9xe7wUcLop5UFJYoCP9t9ex6USNwyTqPBT62Fit9 PEE1YQyeQ4n0/L/ggAitR/HA+5b2Y7lhwGF/KL0xz9gPVeIudWVW6ZJp9hGYxr5NdfER KqJ3ImrPjXvbShg3LdjXDa5SsH6LAHgIhY5glxlZnr0nUamjE0rZeMvN4NdVMy8+Xdu8 LahfmtcdzvYVmut8Bmg/RRz19aNxa7QY1CHXgJnNHwrAXLG9417aiRXVdQzgXw9bgXGn 3oe6jtQEqwQwHKL8z5WfQQIk3ilBd0d8wmodaQjuj0wNKgoXcJUqLndPeG8aAAe63aT7 X9pA== 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 l15si45208oic.220.2020.03.06.09.52.58; Fri, 06 Mar 2020 09:53:11 -0800 (PST) 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 S1726676AbgCFRvR (ORCPT + 99 others); Fri, 6 Mar 2020 12:51:17 -0500 Received: from foss.arm.com ([217.140.110.172]:37088 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725935AbgCFRvR (ORCPT ); Fri, 6 Mar 2020 12:51:17 -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 BC28230E; Fri, 6 Mar 2020 09:51:16 -0800 (PST) Received: from e107158-lin.cambridge.arm.com (e107158-lin.cambridge.arm.com [10.1.195.21]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6BE3F3F6C4; Fri, 6 Mar 2020 09:51:15 -0800 (PST) Date: Fri, 6 Mar 2020 17:51:13 +0000 From: Qais Yousef To: Ingo Molnar , Peter Zijlstra , Steven Rostedt , Dietmar Eggemann , Pavan Kondeti Cc: Juri Lelli , Vincent Guittot , Ben Segall , Mel Gorman , linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 6/6] sched/rt: Fix pushing unfit tasks to a better CPU Message-ID: <20200306175112.vkpeouec2c47yujl@e107158-lin.cambridge.arm.com> References: <20200302132721.8353-1-qais.yousef@arm.com> <20200302132721.8353-7-qais.yousef@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200302132721.8353-7-qais.yousef@arm.com> User-Agent: NeoMutt/20171215 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Pavan On 03/02/20 13:27, Qais Yousef wrote: > If a task was running on unfit CPU we could ignore migrating if the > priority level of the new fitting CPU is the *same* as the unfit one. > > Add an extra check to select_task_rq_rt() to allow the push in case: > > * p->prio == new_cpu.highest_priority > * task_fits(p, new_cpu) > > Fixes: 804d402fb6f6 ("sched/rt: Make RT capacity-aware") > Signed-off-by: Qais Yousef > --- Can you please confirm if you have any objection to this patch? Without it I see large delays in the 2 tasks test like I outlined in [1]. It wasn't clear from [2] whether you are in agreement now or not. [1] https://lore.kernel.org/lkml/20200217135306.cjc2225wdlwqiicu@e107158-lin.cambridge.arm.com/ [2] https://lore.kernel.org/lkml/20200227033608.GN28029@codeaurora.org/ Thanks -- Qais Yousef > kernel/sched/rt.c | 41 ++++++++++++++++++++++++++++------------- > 1 file changed, 28 insertions(+), 13 deletions(-) > > diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c > index ce230bec6847..8aaa442e4867 100644 > --- a/kernel/sched/rt.c > +++ b/kernel/sched/rt.c > @@ -1474,20 +1474,35 @@ select_task_rq_rt(struct task_struct *p, int cpu, int sd_flag, int flags) > if (test || !rt_task_fits_capacity(p, cpu)) { > int target = find_lowest_rq(p); > > - /* > - * Bail out if we were forcing a migration to find a better > - * fitting CPU but our search failed. > - */ > - if (!test && target != -1 && !rt_task_fits_capacity(p, target)) > - goto out_unlock; > + if (target != -1) { > + bool fit_target = rt_task_fits_capacity(p, target); > > - /* > - * Don't bother moving it if the destination CPU is > - * not running a lower priority task. > - */ > - if (target != -1 && > - p->prio < cpu_rq(target)->rt.highest_prio.curr) > - cpu = target; > + /* > + * Bail out if we were forcing a migration to find a > + * better fitting CPU but our search failed. > + */ > + if (!test && !fit_target) > + goto out_unlock; > + > + /* > + * Don't bother moving it if the destination CPU is > + * not running a lower priority task. > + */ > + if (p->prio < cpu_rq(target)->rt.highest_prio.curr) { > + > + cpu = target; > + > + } else if (p->prio == cpu_rq(target)->rt.highest_prio.curr) { > + > + /* > + * If the priority is the same and the new CPU > + * is a better fit, then move, otherwise don't > + * bother here either. > + */ > + if (fit_target) > + cpu = target; > + } > + } > } > > out_unlock: > -- > 2.17.1 >