Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp1946523ybv; Fri, 14 Feb 2020 08:40:53 -0800 (PST) X-Google-Smtp-Source: APXvYqy9wuhT2X82WJtb9TGTIHNE84RpH/ykun6VQ0SknHFOZwNBULbrC8re65bHjH0AC6lKdU4b X-Received: by 2002:aca:ed94:: with SMTP id l142mr2535152oih.58.1581698453493; Fri, 14 Feb 2020 08:40:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581698453; cv=none; d=google.com; s=arc-20160816; b=G01IkXH6yNg2tB+0JmDeEhsTRbTWsIp29nK+mk1s0Dc+rax4bubqCnwan0FQDsyuer YMrxkaKehHyivgedrd1v9QKm2biJ51e7iZvN62/I34K1296yNSGHn8VmJK2FdPJmSH0T 7/FsA+X4u3mwJM4rLuepYdeVbPlpk7M3jl7eufk2X+lhPQFFJMHT6mvx9bHIl9PLhJvD hDC72KGN0+YXPI70rXzGtdaNcmIZMFiZbeeQTH8aFKyAsklzNPObysBv7ctSVRXp/ocD scJdDGR5uSYDRintIkXK9VUFlMza8drNjr6WXOVybkDbgGUzCRp0X6XLlbr0M24JlBvt IGtw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from; bh=oCJkd8Vtq7LYweU8sJpHaXJbqNR+x5bx9FdtvcG9xuU=; b=pjRaVkvFMlKfmmTo99Sbk5WEyFyuyh+6inZQXKzjeFKot5T2LHhf8nTzqYQnGSSVmb rC9Zh4JnSRLrjcsSBVrtAT0JNGE8sIfgq9z+P1kijHbVBoUq9s0zgOurQt5W8JObWQbP ozVJgb3ManBWOlqFwPD1BpsQ9uP3k5JOpFpjROAUQHegugjlYxfXZixbvoRFlD2u880f Mi8SFOooGLXKQJfIK6S/3eZrWGxKibNd4cj+fgQL/ygr8bPbBaCUpPgqihXg1ApQivGW gvcsW3pO8UBtCELHl2LQSuV7WEM/ArUWtywgY1wWz987nPw5WlR1e6wsjAt2RQ1ub9Sf NlGQ== 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 m9si2833170oie.148.2020.02.14.08.40.41; Fri, 14 Feb 2020 08:40:53 -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 S2388726AbgBNQkG (ORCPT + 99 others); Fri, 14 Feb 2020 11:40:06 -0500 Received: from foss.arm.com ([217.140.110.172]:39292 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2405845AbgBNQkD (ORCPT ); Fri, 14 Feb 2020 11:40:03 -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 9A8C1113E; Fri, 14 Feb 2020 08:40:02 -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 30CC23F6CF; Fri, 14 Feb 2020 08:40:01 -0800 (PST) From: Qais Yousef To: Ingo Molnar , Peter Zijlstra , Steven Rostedt , Pavan Kondeti , Dietmar Eggemann Cc: Juri Lelli , Vincent Guittot , Ben Segall , Mel Gorman , linux-kernel@vger.kernel.org, Qais Yousef Subject: [PATCH 3/3] sched/rt: fix pushing unfit tasks to a better CPU Date: Fri, 14 Feb 2020 16:39:49 +0000 Message-Id: <20200214163949.27850-4-qais.yousef@arm.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200214163949.27850-1-qais.yousef@arm.com> References: <20200214163949.27850-1-qais.yousef@arm.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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: * old_cpu.highest_priority == new_cpu.highest_priority * task_fits(p, new_cpu) Signed-off-by: Qais Yousef --- I was seeing some delays in migrating a task to a big CPU sometimes although it was free, and I think this fixes it. TBH, I fail to see how the check of p->prio < cpu_rq(target)->rt.highest_prio.curr is necessary as find_lowest_rq() surely implies the above condition by definition? Unless we're fighting a race condition here where the rt_rq priority has changed between the time we selected the lowest_rq and taking the decision to migrate, then this makes sense. kernel/sched/rt.c | 34 +++++++++++++++++++++++++--------- 1 file changed, 25 insertions(+), 9 deletions(-) diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c index 0c8bac134d3a..5ea235f2cfe8 100644 --- a/kernel/sched/rt.c +++ b/kernel/sched/rt.c @@ -1430,7 +1430,7 @@ select_task_rq_rt(struct task_struct *p, int cpu, int sd_flag, int flags) { struct task_struct *curr; struct rq *rq; - bool test; + bool test, fit; /* For anything but wake ups, just return the task_cpu */ if (sd_flag != SD_BALANCE_WAKE && sd_flag != SD_BALANCE_FORK) @@ -1471,16 +1471,32 @@ select_task_rq_rt(struct task_struct *p, int cpu, int sd_flag, int flags) unlikely(rt_task(curr)) && (curr->nr_cpus_allowed < 2 || curr->prio <= p->prio); - if (test || !rt_task_fits_capacity(p, cpu)) { + fit = rt_task_fits_capacity(p, cpu); + + if (test || !fit) { int target = find_lowest_rq(p); - /* - * 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; + if (target != -1) { + /* + * 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. + */ + fit = rt_task_fits_capacity(p, target); + if (fit) + cpu = target; + } + } } rcu_read_unlock(); -- 2.17.1