Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp292124pxf; Thu, 11 Mar 2021 04:08:42 -0800 (PST) X-Google-Smtp-Source: ABdhPJzAElh1ZMkWdIlY/ARP7KnXI9s6rILa8r2/6bfxh/yjoU/ZI1dU7cKoJz1Re+cxxOOWKct0 X-Received: by 2002:a17:906:33da:: with SMTP id w26mr2761571eja.302.1615464522073; Thu, 11 Mar 2021 04:08:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615464522; cv=none; d=google.com; s=arc-20160816; b=fCCNGe4Ln9HJd4zbJUB0dwfTj1dY9/YMCBs28JN7CO62rIXt+DiJAmCoHGMU6k4YJx KRsoLwVM9p6Tp4uMeTadXTFSUGgONJDK7Rc/i3Wx1bLQWJCb5mwXxp9RTyt4ImRieZpw OBOGhX0iRhOW3MOu2Fuxchym+srBQcAGE84H14LYpuGMDkQiDqBQp4VjlGJnF+88ujQY qQFfdL7Vf/UpuF2uxQ6XbYcNJRZ0/cyoU1/5PYko6VL0opth/Fpam2FjiHhISDsVF+QS MQ5A0JF2oOFU9KCqc0URgSiEjseqf63A+uqd+QqQgcKdRh2x2O9rt8ja7Hdc7c6KrPyq Gngg== 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=VqZNWF1/mpFEO3OzuKPLfHNBNI00ybeVejxa4XxhOCg=; b=DrxyBhzFO1hzFqBCXyAxL8KIFN00+iHok3u9z6t9xfLkZdVu27GaHIEKaj+a33BtgJ loNXq5wcybTryVWLE3CWSIawqPNV67UeTpqo8jL5uPwo0AhFVpnem8dV77VTUWija89M JMR2ZRozk9tXr3zQEnh2Rn9ArYlAbk9soKqLQsW7H836aKu7w5RZlEe9bJ5EHc2X1vWB a1YmGSS56qXeD32uJMtw/Wyzv/dtw4bfnXpdTk7kgO3/W9QotaQJsy6nn3JBvIYILGzn lZD2TqDh51/j8q1KwzTvs8zMof1y683ypa+s3TZo4ZwvWR3ng1C05+z+RMpB4oWoXEOH M9VA== 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 cw1si1726859edb.412.2021.03.11.04.08.19; Thu, 11 Mar 2021 04:08:42 -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 S233087AbhCKMGK (ORCPT + 99 others); Thu, 11 Mar 2021 07:06:10 -0500 Received: from foss.arm.com ([217.140.110.172]:34118 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233028AbhCKMFs (ORCPT ); Thu, 11 Mar 2021 07:05:48 -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 D541912FC; Thu, 11 Mar 2021 04:05:47 -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 4B1883F793; Thu, 11 Mar 2021 04:05:46 -0800 (PST) From: Valentin Schneider To: linux-kernel@vger.kernel.org Cc: Qais Yousef , Peter Zijlstra , Ingo Molnar , Vincent Guittot , Dietmar Eggemann , Morten Rasmussen , Quentin Perret , Pavan Kondeti , Rik van Riel , Lingutla Chandrasekhar Subject: [PATCH v3 7/7] sched/fair: Relax task_hot() for misfit tasks Date: Thu, 11 Mar 2021 12:05:27 +0000 Message-Id: <20210311120527.167870-8-valentin.schneider@arm.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210311120527.167870-1-valentin.schneider@arm.com> References: <20210311120527.167870-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 Consider the following topology: DIE [ ] MC [ ][ ] 0 1 2 3 capacity_orig_of(x \in {0-1}) < capacity_orig_of(x \in {2-3}) w/ CPUs 2-3 idle and CPUs 0-1 running CPU hogs (util_avg=1024). When CPU2 goes through load_balance() (via periodic / NOHZ balance), it should pull one CPU hog from either CPU0 or CPU1 (this is misfit task upmigration). However, should a e.g. pcpu kworker awake on CPU0 just before this load_balance() happens and preempt the CPU hog running there, we would have, for the [0-1] group at CPU2's DIE level: o sgs->sum_nr_running > sgs->group_weight o sgs->group_capacity * 100 < sgs->group_util * imbalance_pct IOW, this group is group_overloaded. Considering CPU0 is picked by find_busiest_queue(), we would then visit the preempted CPU hog in detach_tasks(). However, given it has just been preempted by this pcpu kworker, task_hot() will prevent it from being detached. We then leave load_balance() without having done anything. Long story short, preempted misfit tasks are affected by task_hot(), while currently running misfit tasks are intentionally preempted by the stopper task to migrate them over to a higher-capacity CPU. Align detach_tasks() with the active-balance logic and let it pick a cache-hot misfit task when the destination CPU can provide a capacity uplift. Reviewed-by: Qais Yousef Signed-off-by: Valentin Schneider --- kernel/sched/fair.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 41cdda7a8ea6..5454429cea7a 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -7474,6 +7474,17 @@ static int task_hot(struct task_struct *p, struct lb_env *env) if (env->sd->flags & SD_SHARE_CPUCAPACITY) return 0; + /* + * On a (sane) asymmetric CPU capacity system, the increase in compute + * capacity should offset any potential performance hit caused by a + * migration. + */ + if (sd_has_asym_cpucapacity(env->sd) && + env->idle != CPU_NOT_IDLE && + !task_fits_capacity(p, capacity_of(env->src_cpu)) && + cpu_capacity_greater(env->dst_cpu, env->src_cpu)) + return 0; + /* * Buddy candidates are cache hot: */ -- 2.25.1