Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp8001267pxb; Fri, 19 Feb 2021 05:06:37 -0800 (PST) X-Google-Smtp-Source: ABdhPJzHghXhvcgI0m6/vOk7Eu4GQ6PUenA2iVP85Ojw529IPU28UkRpmlJv05jbl31EhoMYi2Uq X-Received: by 2002:a17:906:5495:: with SMTP id r21mr8793623ejo.59.1613739997423; Fri, 19 Feb 2021 05:06:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613739997; cv=none; d=google.com; s=arc-20160816; b=bBYuNgr5VNXgqAWhRxJWnUkpbzcX9lhbcFRCZAMp2knFs8VBNNOpsgp1ysKinYdPS4 YAa6RmOkgHOGV2xyma10sZ4ef5e/fd0lfgCQ+8aB145sO6w8Rs1KoU5krNLkqqniodIy GjKbNOygypg9sSp/Gc46y1aPqIeCKlr9kloUt1PMRhWVWRAOpx/A8LW2RViEBxwuZAnr DYDH839gi/RyqwC9U+B4noC9lDu9+Py4U9CCotREzUVQ6sDFDAUWIQ1GlyD9TbD4t+2F K3rTjVHKMExY4+UvnVRfr/VOe6Ln+HH9lOyNaB9iqaRMuS613xUjRfek0fMWono34YYv yXWQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=zcV3wrS9cgSxrZRMocnbvDXBTwdT91RIg18p9gj8Uys=; b=JQLJhmi8kNe/j9lhrGKyPZtMEW6BwR3VM6XKFCNk5kF4VssP/lom+P7kOEL3EeO7KH SH92CGNDEBVVJ5L36amfGIjNNBjr4c9oXlcvmm6gW91EjHW+OTwzEpV66sn1hUsAQlIo nPVhpIMGHN+V7I44bG+oAL0w0C/fODKeeUTqcYNRNurHVGAYm3HkoDpFcbHie+x/sWeT XlnUrQegJpgv2w6vJWFi4b6xgjEIjH5KCBomMHMYZa5w5MJTePTY4iw4uxfRIa/d7rVm S5GgDojPdtOzUq++YVnDuWTFJCn+CEs2+DmJ/uKKc31EGevXtlu1B3S46xDJcmFj/ESv oquQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ga26si906843ejb.236.2021.02.19.05.06.11; Fri, 19 Feb 2021 05:06:37 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230195AbhBSND2 (ORCPT + 99 others); Fri, 19 Feb 2021 08:03:28 -0500 Received: from foss.arm.com ([217.140.110.172]:35852 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230031AbhBSNDT (ORCPT ); Fri, 19 Feb 2021 08:03:19 -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 D7E4E11FB; Fri, 19 Feb 2021 05:02:33 -0800 (PST) Received: from e113632-lin.cambridge.arm.com (e113632-lin.cambridge.arm.com [10.1.194.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 50D0F3F73B; Fri, 19 Feb 2021 05:02:32 -0800 (PST) From: Valentin Schneider To: linux-kernel@vger.kernel.org Cc: Peter Zijlstra , Ingo Molnar , Vincent Guittot , Dietmar Eggemann , Morten Rasmussen , Qais Yousef , Quentin Perret , Pavan Kondeti , Rik van Riel , Lingutla Chandrasekhar Subject: [PATCH v2 2/7] sched/fair: Clean up active balance nr_balance_failed trickery Date: Fri, 19 Feb 2021 12:59:58 +0000 Message-Id: <20210219130003.2890-3-valentin.schneider@arm.com> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20210219130003.2890-1-valentin.schneider@arm.com> References: <20210219130003.2890-1-valentin.schneider@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 2d4dcf1a3372..535ebc31c9a8 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -7394,6 +7394,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; @@ -7583,10 +7584,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; + tsk_cache_hot = migrate_degrades_locality(p, env); if (tsk_cache_hot == -1) tsk_cache_hot = task_hot(p, env); @@ -9780,9 +9785,6 @@ static int load_balance(int this_cpu, struct rq *this_rq, active_load_balance_cpu_stop, busiest, &busiest->active_balance_work); } - - /* We've kicked active balancing, force task migration. */ - sd->nr_balance_failed = sd->cache_nice_tries+1; } } else { sd->nr_balance_failed = 0; @@ -9938,7 +9940,8 @@ static int active_load_balance_cpu_stop(void *data) * @dst_grpmask we need to make that test go away with lying * about DST_PINNED. */ - .flags = LBF_DST_PINNED, + .flags = LBF_DST_PINNED | + LBF_ACTIVE_LB, }; schedstat_inc(sd->alb_count); -- 2.27.0