Received: by 10.223.185.116 with SMTP id b49csp382801wrg; Fri, 16 Feb 2018 00:10:14 -0800 (PST) X-Google-Smtp-Source: AH8x225zYr+PSyEI/fRRR75LrjIplq6JYv3k/25KRdDxwpV7a/3kZx1hPL7UJBLiBvfmKzQWkLol X-Received: by 10.99.123.92 with SMTP id k28mr4501885pgn.167.1518768614143; Fri, 16 Feb 2018 00:10:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518768614; cv=none; d=google.com; s=arc-20160816; b=q0QoRJF25UkMRJ16CRsuf8p2rz/RXekHmtWayGI4ChOlOOx2AyXU5HY0J9Xw0YNBy3 VI/O0lNoBHqOEHs7AH1fJMSpnmNDgmBmCxQC7REmJQpxoLxHwpplMSnSHXnaoK1ef0zr VWzgLoL3BDue8hPrcTS+36njmzHOgZSdXpaRgMHp3YtebUQF6HtyF72qarHIhGY6tuJO G5O2BPiuZhWVRdSuMzs7Wx39lEl7lc3JlSjg1ECVGusMynBETZe33MKMKXvVTLpK5H3m Y7EfzIydTQLA6kkVf8uwfEem2mPEwLXz0LekIzdWagAI74BKK4VW9cjBICSUMzs6gEof m9RA== 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:arc-authentication-results; bh=p6M3iK9bYm2ZpLR90XLe9sH5DnVtr26spsQ7YALJWwM=; b=GmyGiHkkZx7tH4grcAmjaamGjnzp5zyqAJYm2ojaSIvJdkOPL9N3TulRW/ot/Urhu+ kOrBvuVA0ISeuUUqfLKr12VfC4ei8itSv/7Bs5LTmcSP2Jknc+n2jS+Dkh6TL2pPCxjn FIE6sVPURb/YE+aLVxxlVZ55fEjKJLLueV250LB3NXsTvE+iVKkM5E/cqjKrvz7l7ogB WdCi5wFdpzWgqVJUQn4YRB70p8ssMwcKVowacfri/WwqAh3RzAtejmlH/IBRv8q5e+ko llXGUs41Dk2UfwUEefHPEJ2OmzBNCZb57ilaVoUIBldtRpU/R+WL73kfajdETUH9bDY4 5cLg== 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 k2si4134129pfi.205.2018.02.16.00.09.59; Fri, 16 Feb 2018 00:10:14 -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 S1425775AbeBOQWW (ORCPT + 99 others); Thu, 15 Feb 2018 11:22:22 -0500 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:57136 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1425717AbeBOQVf (ORCPT ); Thu, 15 Feb 2018 11:21:35 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 69DC91682; Thu, 15 Feb 2018 08:21:35 -0800 (PST) Received: from e105550-lin.cambridge.arm.com (e105550-lin.cambridge.arm.com [10.1.211.30]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 13E823F24D; Thu, 15 Feb 2018 08:21:33 -0800 (PST) From: Morten Rasmussen To: peterz@infradead.org, mingo@redhat.com Cc: valentin.schneider@arm.com, dietmar.eggemann@arm.com, vincent.guittot@linaro.org, linux-kernel@vger.kernel.org, Morten Rasmussen Subject: [PATCH 7/7] sched/fair: Set sd->should_idle_balance when misfit Date: Thu, 15 Feb 2018 16:20:54 +0000 Message-Id: <1518711654-23503-8-git-send-email-morten.rasmussen@arm.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1518711654-23503-1-git-send-email-morten.rasmussen@arm.com> References: <1518711654-23503-1-git-send-email-morten.rasmussen@arm.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Valentin Schneider Idle balance is a great opportunity to pull a misfit task. However, there are scenarios where misfit tasks are present but idle balance is prevented by the should_idle_balance flag. A good example of this is a workload of n identical tasks. Let's suppose we have a 2+2 Arm big.LITTLE system. We then spawn 4 fairly CPU-intensive tasks - for the sake of simplicity let's say they are just CPU hogs, even when running on big CPUs. They are identical tasks, so on an SMP system they should all end at (roughly) the same time. However, in our case the LITTLE CPUs are less performing than the big CPUs, so tasks running on the LITTLEs will have a longer completion time. This means that the big CPUs will complete their work earlier, at which point they should pull the tasks from the LITTLEs. What we want to happen is summarized as follows: a,b,c,d are our CPU-hogging tasks _ signifies idling LITTLE_0 | a a a a _ _ LITTLE_1 | b b b b _ _ ---------|------------- big_0 | c c c c a a big_1 | d d d d b b ^ ^ Tasks end on the big CPUs, idle balance happens and the misfit tasks are pulled straight away This however won't happen, because currently the should_idle_balance flag is only set when there is any CPU that has more than one runnable task - which may very well not be the case here if our CPU-hogging workload is all there is to run. As such, this commit sets the should_idle_balance flag in update_sg_lb_stats when a group is flagged as having a misfit task. cc: Ingo Molnar cc: Peter Zijlstra Signed-off-by: Valentin Schneider Signed-off-by: Morten Rasmussen --- kernel/sched/fair.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 2d2302b7b584..d080a144f87f 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -7871,8 +7871,10 @@ static inline void update_sg_lb_stats(struct lb_env *env, sgs->idle_cpus++; if (env->sd->flags & SD_ASYM_CPUCAPACITY && - !sgs->group_misfit_task_load && rq->misfit_task_load) + !sgs->group_misfit_task_load && rq->misfit_task_load) { sgs->group_misfit_task_load = rq->misfit_task_load; + *should_idle_balance = true; + } } /* Adjust by relative CPU capacity of the group */ -- 2.7.4