From patchwork Fri Nov 29 14:04:47 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vincent Guittot X-Patchwork-Id: 180485 Delivered-To: patch@linaro.org Received: by 2002:a92:3001:0:0:0:0:0 with SMTP id x1csp1605053ile; Fri, 29 Nov 2019 06:05:47 -0800 (PST) X-Google-Smtp-Source: APXvYqwa/gRDkto5wObf8fG3sAABsYyWlYQi2SvKGdv5PQoCLtSUr5PdnhU3LHDWmwA718hHI2JN X-Received: by 2002:a50:da43:: with SMTP id a3mr45092654edk.229.1575036347588; Fri, 29 Nov 2019 06:05:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1575036347; cv=none; d=google.com; s=arc-20160816; b=H4tUbVXc8Voie2E08WqU82r4f+3glWuAho2mdUwhLQBF2pAAsom0mSzoe6QPMgceaw +LRQurgDZzqKeJX6laMhmmzp8FJITtbmfaKCUk+/X5UD5Gmo2SBsyvL+xYku8jzkVBqn HyLSiXZSBAx7JpLuOODBnHiSGVNPyl1FRGUqxPgrLIV15yb7YCmvU6h/KCFX99EwLV9P zcnVmh0SmP6uK2opwteo4xgLZ3f/79Pyyff4vhxlP53z6UMl22meVGrTWgTtiL5dBP9p Kq+bHk+Ee3GzxRuxTI1d7Rgtv4XEM98LV4Lj00VJoEjGA+U11rZdXK+mN9pQQS+MyDqz UrfA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dkim-signature; bh=iPGXcngV7gc8XOhdKzAAwDcDJ65rcOda9DJ67kLXj4k=; b=LYyQMK5XcS5hYQLWaEx6aiFvj1+EArDEpOh3tWXfQfMZU70e45WYu+qg0QcMqYgjx+ IkBinXN0ThqXEw3SYilZiyqylutnuVIb0YlRL3VhQM6gwkokV5j6Xoodrej0WeBp9EkL 26QK2m6OjxvK/qgotftTUKk2/3fesSCgKmABaczHhDTG/7PYQdDgS43gjqy4iHz1LzeM sNu7MEm62KrEZRb/ZTdNMzlpt+CcQj02FSyfDHgOGL7G6/QYlrAjhzcRZLCXtz/DgpTV hjW1a1lVchLU/i57E8xAXvLl0Z7SSGzRHrceb0y94F3MgLRcxHzBR1yekzUKrfP3kfTK Fq1Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=cOYbbdG1; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t18si16133123eds.247.2019.11.29.06.05.40; Fri, 29 Nov 2019 06:05:47 -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; dkim=pass header.i=@linaro.org header.s=google header.b=cOYbbdG1; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726916AbfK2OFg (ORCPT + 27 others); Fri, 29 Nov 2019 09:05:36 -0500 Received: from mail-wm1-f65.google.com ([209.85.128.65]:53278 "EHLO mail-wm1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726763AbfK2OFg (ORCPT ); Fri, 29 Nov 2019 09:05:36 -0500 Received: by mail-wm1-f65.google.com with SMTP id u18so14313076wmc.3 for ; Fri, 29 Nov 2019 06:05:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id; bh=iPGXcngV7gc8XOhdKzAAwDcDJ65rcOda9DJ67kLXj4k=; b=cOYbbdG1IlRBWl2RJ0R8oige9Y+cIW9lbyUGtDErNupd+VWfdoeeQnlPAa/Ksg5TJl NRFd/VcHwUFD9B59CKzW7HF7G+f8KXBsgw/FzUNheIlNwa8SM/Lmzpve/nTJ4VSDs61v /LhfUSy30og1Fgssip616rTKzqv5nxFFo0iWnKemwGuqknMTwYiBhZtfbEoAlBZD/iuc vNH7lrUqpn4wSVjQA3obtwBMh0kqrJg5ByWb5/VOiqgFmNUmgP4JMGzAeXMef47ZGsfS HRCiEqQXpggkzqFiuoYL/RgZHgwDPz1IGeYNz+hXxMpLX0JX+1DwBF1OsHegD2wjtO83 AT9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=iPGXcngV7gc8XOhdKzAAwDcDJ65rcOda9DJ67kLXj4k=; b=G62Fhwp5xRDyvHw3MwKcirdX2b/CYmJLGkiq67ATKaBszfwr6zOAh+mtqymUek77R9 xx4TEEV5efwUKsnl3ciLN6cE/jd4Q1X1SR6/rPb/8cbeq1VDEzXsCV3IeIighSe2Ej1w z8iYnREgXZc4mVgeX9QL16le05vGGD208egA3+1U5xzqrQcicf26cfPt+o5H/AsQGuO9 p41BQ/j679lbeJBcb5qI/7NAIOGJtle5RlCaiZ5IBVdJr1B8v2+xPGzdjEagY3q80tYs wgOzHTa3ld2oQfSR9epd/tNSLuFySlUBGrnhByJtZYl6xCYoS/0NbNt/UH6v6je5GPvz zX8A== X-Gm-Message-State: APjAAAUDb5mXFktQ+wvLPsFVR5vpXWm/PmKq+WXJteNgSMxsXi/UBisv jNbQQk9dbg0j8q+nOtsYnRsPZQ== X-Received: by 2002:a05:600c:2549:: with SMTP id e9mr14431487wma.177.1575036332011; Fri, 29 Nov 2019 06:05:32 -0800 (PST) Received: from localhost.localdomain ([2a01:e0a:f:6020:7d72:5485:2a04:b211]) by smtp.gmail.com with ESMTPSA id k20sm12838804wmj.10.2019.11.29.06.05.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 29 Nov 2019 06:05:29 -0800 (PST) From: Vincent Guittot To: mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, linux-kernel@vger.kernel.org Cc: Vincent Guittot Subject: [PATCH] sched/cfs: fix spurious active migration Date: Fri, 29 Nov 2019 15:04:47 +0100 Message-Id: <1575036287-6052-1-git-send-email-vincent.guittot@linaro.org> X-Mailer: git-send-email 2.7.4 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The load balance can fail to find a suitable task during the periodic check because the imbalance is smaller than half of the load of the waiting tasks. This results in the increase of the number of failed load balance, which can end up to start an active migration. This active migration is useless because the current running task is not a better choice than the waiting ones. In fact, the current task was probably not running but waiting for the CPU during one of the previous attempts and it had already not been selected. When load balance fails too many times to migrate a task, we should relax the contraint on the maximum load of the tasks that can be migrated similarly to what is done with cache hotness. Before the rework, load balance used to set the imbalance to the average load_per_task in order to mitigate such situation. This increased the likelihood of migrating a task but also of selecting a larger task than needed while more appropriate ones were in the list. Signed-off-by: Vincent Guittot --- I haven't seen any noticable performance changes on the benchmarks that I usually run but the problem can be easily highlight with a simple test with 9 always running tasks on 8 cores. kernel/sched/fair.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) -- 2.7.4 diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index e0d662a..d1b4fa7 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -7433,7 +7433,14 @@ static int detach_tasks(struct lb_env *env) load < 16 && !env->sd->nr_balance_failed) goto next; - if (load/2 > env->imbalance) + /* + * Make sure that we don't migrate too much load. + * Nevertheless, let relax the constraint if + * scheduler fails to find a good waiting task to + * migrate. + */ + if (load/2 > env->imbalance && + env->sd->nr_balance_failed <= env->sd->cache_nice_tries) goto next; env->imbalance -= load;