Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp1821611imm; Thu, 9 Aug 2018 02:32:22 -0700 (PDT) X-Google-Smtp-Source: AA+uWPyi/dhVhf/oipc0KUYnsZHwUySYG37rglIzhwgu0QtIX45BnDuUzeMGEia7sUbwe5TyM3AE X-Received: by 2002:a63:8e41:: with SMTP id k62-v6mr1371738pge.187.1533807142789; Thu, 09 Aug 2018 02:32:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533807142; cv=none; d=google.com; s=arc-20160816; b=WF5ZsZKIJX1lE5GZJ7tcVEyo8VFF9vkOAVufOJj4ehAl5hB8oy8LDsLt99is/RgCXp xnsqkg8c9muv+HchfTc6FFp5/nr2LUEvnsbigfpE7/AuRMpQFfNiUbHMi4LUXbwUnMDT z3i5lNf9fJ4+QDoQfmC0NxaibADeHyhoY8Ev8fC1QrKaucEzTas+HLUFnqyTwcwOLc/V hAn0+xF2M4KQUMMh+hl8RqWav3XD6LNSyaLMTZJSecP94+MYoHQEqdcUyvKU5zkkhVWP rwl0ZW/sOerP8w187U62D3uPNaCapKCsT0abZnO9zBKhRfy6tq1nL/BeSzN94WuLze+A gqiQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature :arc-authentication-results; bh=wtuPyPk64r09cO3EtqFJAP42zGzxwKzl724zbBNMBPc=; b=SD6N58siZ+0YxRCYGn7y6KWSSWKbIiRNzleG0oYhD6qmK/wI6x1/vhjklqhE8rZvRs DhfHYTk7XLyjacd03ZT15wSxma9fv+KDMRqEo0WpHuRcYehk1suGAU6Er+CKs4dYSfTs pJ7aQp3r/1po0/lHRonrSd7yO8G6wsQR7MYRLufdP1+JM/ERm3NUanDUuY6Yd2QQCfmR Gcd9J4cOu1KLPnJiDAlM2I27JjNKyyY+F1D1gMZZ9DRwM+RSghtXIWnskJfA09OdDmwA tPHOajDluJR0L2Kih76ZvExXRZJDHtxInBEuy3Gj+F9dZGVzVh+MXjUhqcSWivf7rQ8i ylUQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=D3FZ8tFu; 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 g16-v6si6626799pgi.373.2018.08.09.02.32.08; Thu, 09 Aug 2018 02:32:22 -0700 (PDT) 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=D3FZ8tFu; 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 S1730081AbeHILzJ (ORCPT + 99 others); Thu, 9 Aug 2018 07:55:09 -0400 Received: from mail-io0-f195.google.com ([209.85.223.195]:41061 "EHLO mail-io0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727579AbeHILzJ (ORCPT ); Thu, 9 Aug 2018 07:55:09 -0400 Received: by mail-io0-f195.google.com with SMTP id q4-v6so4219221iob.8 for ; Thu, 09 Aug 2018 02:31:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wtuPyPk64r09cO3EtqFJAP42zGzxwKzl724zbBNMBPc=; b=D3FZ8tFunAx13zmr9bDIlI66bSUG7V4Uh1CaoEzmHr5ZT8OPCjCTovNg5CjDjeIaE3 GRY+HU9TRx2YPC4dqOcuidNFRL+AI1LyD7UK92PEQaY1vOpsn2+azqZqhGu5ZxfN18CI FPHKQk93oSfB1YehdExkOvrbPEYE10ojVSmPk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wtuPyPk64r09cO3EtqFJAP42zGzxwKzl724zbBNMBPc=; b=KlQQ84iUScRyo/TOoCkhJW9eegqvR/dMP+b1+ks8mYx8IiXQ0MRukXkRJQsF+GlFyN gQKKRfRrRpTqBp9Xn88zC2Mx1/8qsK9H2f6N0EKm4LC6SWZspGPl3kD3Ju5/2qc/lHt6 MbmrHrF23NgF+ZTw/Vzr1iPMt8Aouosb8lZ+wpcGmEB9ciFc4is558+toi1XVBms8CC8 l5ficum0wrKQs+3Myhuh77N+ln5k/HUwJ0K/4rUN84B6tFun8HBsZpmKHqRhs8oOBCe9 SCZ+KhhMZEeg8eEGlEZk5nSO9YAZZlZZlqQQldt7VwBd0PjYzsBZbez5ZQgsACsihIbK dBoQ== X-Gm-Message-State: AOUpUlGtNwpDTncvJEwyRVEPjRprKFiukOOcumabTFIXBJWFn/XjLKBH e9QW2DBXVGQ4Htfv/eXYw4WUbYdrFl0Gv6lPQhFOIQ== X-Received: by 2002:a6b:ec0f:: with SMTP id c15-v6mr1075360ioh.18.1533807068698; Thu, 09 Aug 2018 02:31:08 -0700 (PDT) MIME-Version: 1.0 References: <20180724122521.22109-1-quentin.perret@arm.com> <20180724122521.22109-10-quentin.perret@arm.com> In-Reply-To: <20180724122521.22109-10-quentin.perret@arm.com> From: Vincent Guittot Date: Thu, 9 Aug 2018 11:30:57 +0200 Message-ID: Subject: Re: [PATCH v5 09/14] sched: Add over-utilization/tipping point indicator To: Quentin Perret Cc: Peter Zijlstra , "Rafael J. Wysocki" , linux-kernel , "open list:THERMAL" , "gregkh@linuxfoundation.org" , Ingo Molnar , Dietmar Eggemann , Morten Rasmussen , Chris Redpath , Patrick Bellasi , Valentin Schneider , Thara Gopinath , viresh kumar , Todd Kjos , Joel Fernandes , "Cc: Steve Muckle" , adharmap@quicinc.com, "Kannan, Saravana" , pkondeti@codeaurora.org, Juri Lelli , Eduardo Valentin , Srinivas Pandruvada , currojerez@riseup.net, Javi Merino Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 24 Jul 2018 at 14:26, Quentin Perret wrote: > > From: Morten Rasmussen > > Energy-aware scheduling is only meant to be active while the system is > _not_ over-utilized. That is, there are spare cycles available to shift > tasks around based on their actual utilization to get a more > energy-efficient task distribution without depriving any tasks. When > above the tipping point task placement is done the traditional way based > on load_avg, spreading the tasks across as many cpus as possible based > on priority scaled load to preserve smp_nice. Below the tipping point we > want to use util_avg instead. We need to define a criteria for when we > make the switch. > > The util_avg for each cpu converges towards 100% (1024) regardless of remove the "(1024)" because util_avg converges to max cpu capacity which can be different from 1024 > how many task additional task we may put on it. If we define > over-utilized as: > > sum_{cpus}(rq.cfs.avg.util_avg) + margin > sum_{cpus}(rq.capacity) > > some individual cpus may be over-utilized running multiple tasks even > when the above condition is false. That should be okay as long as we try > to spread the tasks out to avoid per-cpu over-utilization as much as > possible and if all tasks have the _same_ priority. If the latter isn't > true, we have to consider priority to preserve smp_nice. >