From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 03519C433DB for ; Fri, 5 Feb 2021 23:31:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BC2AB64D9A for ; Fri, 5 Feb 2021 23:31:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230316AbhBEXab (ORCPT ); Fri, 5 Feb 2021 18:30:31 -0500 Received: from foss.arm.com ([217.140.110.172]:35236 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232578AbhBEOX1 (ORCPT ); Fri, 5 Feb 2021 09:23:27 -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 F1EBA31B; Fri, 5 Feb 2021 06:05:41 -0800 (PST) Received: from e113632-lin (e113632-lin.cambridge.arm.com [10.1.194.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9EDC63F719; Fri, 5 Feb 2021 06:05:40 -0800 (PST) From: Valentin Schneider To: Vincent Guittot Cc: linux-kernel , Peter Zijlstra , Ingo Molnar , Dietmar Eggemann , Morten Rasmussen , Qais Yousef , Quentin Perret , Pavan Kondeti , Rik van Riel Subject: Re: [PATCH 1/8] sched/fair: Clean up active balance nr_balance_failed trickery In-Reply-To: References: <20210128183141.28097-1-valentin.schneider@arm.com> <20210128183141.28097-2-valentin.schneider@arm.com> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/26.3 (x86_64-pc-linux-gnu) Date: Fri, 05 Feb 2021 14:05:35 +0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/02/21 14:51, Vincent Guittot wrote: > On Thu, 28 Jan 2021 at 19:32, Valentin Schneider > wrote: >> >> When triggering an active load balance, sd->nr_balance_failed is set to >> such a value that any further can_migrate_task() using said sd will ignore >> the output of task_hot(). >> >> This behaviour makes sense, as active load balance intentionally preempts a >> rq's running task to migrate it right away, but this asynchronous write is >> a bit shoddy, as the stopper thread might run active_load_balance_cpu_stop >> before the sd->nr_balance_failed write either becomes visible to the >> stopper's CPU or even happens on the CPU that appended the stopper work. >> >> Add a struct lb_env flag to denote active balancing, and use it in >> can_migrate_task(). Remove the sd->nr_balance_failed write that served the >> same purpose. >> >> Signed-off-by: Valentin Schneider >> --- >> kernel/sched/fair.c | 17 ++++++++++------- >> 1 file changed, 10 insertions(+), 7 deletions(-) >> >> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c >> index 197a51473e0c..0f6a4e58ce3c 100644 >> --- a/kernel/sched/fair.c >> +++ b/kernel/sched/fair.c >> @@ -7423,6 +7423,7 @@ enum migration_type { >> #define LBF_SOME_PINNED 0x08 >> #define LBF_NOHZ_STATS 0x10 >> #define LBF_NOHZ_AGAIN 0x20 >> +#define LBF_ACTIVE_LB 0x40 >> >> struct lb_env { >> struct sched_domain *sd; >> @@ -7608,10 +7609,14 @@ int can_migrate_task(struct task_struct *p, struct lb_env *env) >> >> /* >> * Aggressive migration if: >> - * 1) destination numa is preferred >> - * 2) task is cache cold, or >> - * 3) too many balance attempts have failed. >> + * 1) active balance >> + * 2) destination numa is preferred >> + * 3) task is cache cold, or >> + * 4) too many balance attempts have failed. >> */ >> + if (env->flags & LBF_ACTIVE_LB) >> + return 1; >> + > > This changes the behavior for numa system because it skips > migrate_degrades_locality() which can return 1 and prevent active > migration whatever nr_balance_failed > > Is that intentional ? > If I read this right, the result of migrate_degrades_locality() is (currently) ignored if env->sd->nr_balance_failed > env->sd->cache_nice_tries While on the load_balance() side, we have: /* We've kicked active balancing, force task migration. */ sd->nr_balance_failed = sd->cache_nice_tries+1; So we should currently be ignoring migrate_degrades_locality() in the active balance case - what I wrote in the changelog for task_hot() still applies to migrate_degrades_locality().