Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp222056imm; Thu, 26 Jul 2018 02:18:28 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfKdEaBRDyEWIvhhfDr8fNyuTCQsDL1rMb1hkhY/7nh8lYcBicPykhuFgzjX8xahfl5hNhf X-Received: by 2002:a17:902:294a:: with SMTP id g68-v6mr1266359plb.58.1532596708266; Thu, 26 Jul 2018 02:18:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532596708; cv=none; d=google.com; s=arc-20160816; b=eJDyZC+md6oi81J5lKSINGkvA1R4Ur4zjJA+Oict1w11h+Ll3MGSy5AoUbsCSJ1GJ2 3k03r5IZ5mTI363vM5YuFyFjgDdhyZM0k8OpN2mlFnJ6hpo66aUR4BwS1xqIr2DgCqMY qAJLeScglWC77Jo1c5Q9GDO0DCLKLBy9Uxgwhflhg31r+B4SiTMjCJYULb5tVaBpmJS0 n4/ZCca75BP6sA9dRsy1m1TTXX2VqNckCBRZHP6zawTBZt7Ihx0fR2qGvnJ+X90PUOn3 weZ1nBRN0O9O0wbqCzqsYee5mRxnicwF6iBt8UeyRy3hZFi5CsYvdhiw3d9Ak1NpgeEx PnwA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=kZRcU28HE7K3mwqyAVpahzSfqFPmSA2oB35jXR3wfIw=; b=YINeKrWg75kXHlUTZII7Cpv3NGMMX8QjJ5xaPGZC82Nl7sgI268D5sEwqMCwis1VtV pAxhrP9pNuzbRFbqAHV/xLp/kUEbwQTBbE/wWp0UOspf6WvA6fTFYVdcpm2HlhCUCgxH YOE/FxtuMgzyNAOo/wXLKLK272ULpATe2WwAxkGW23+/eq2ywAFR+hTEhS7vQzmAN0hU TO7tqokP2i/E/cJhitv0UzweZ8HMP2O2/hVTE5jeAdgFD6RPFoYBGhe8waNNwzZMjDpz lk2JMnGVR1p5HWXcssieT6rp5AArmVzQxoziXtI3tLRkAr4yA63P3RSkYjx7DVEtR5rx UG4Q== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x9-v6si614412plo.377.2018.07.26.02.18.13; Thu, 26 Jul 2018 02:18:28 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729157AbeGZKcm (ORCPT + 99 others); Thu, 26 Jul 2018 06:32:42 -0400 Received: from cloudserver094114.home.pl ([79.96.170.134]:50476 "EHLO cloudserver094114.home.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728446AbeGZKcm (ORCPT ); Thu, 26 Jul 2018 06:32:42 -0400 Received: from 79.184.255.17.ipv4.supernova.orange.pl (79.184.255.17) (HELO aspire.rjw.lan) by serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer 0.83) id 266f98e022b82640; Thu, 26 Jul 2018 11:16:44 +0200 From: "Rafael J. Wysocki" To: Ulf Hansson Cc: Sudeep Holla , Lorenzo Pieralisi , Mark Rutland , linux-pm@vger.kernel.org, Kevin Hilman , Lina Iyer , Lina Iyer , Rob Herring , Daniel Lezcano , Thomas Gleixner , Vincent Guittot , Stephen Boyd , Juri Lelli , Geert Uytterhoeven , linux-arm-kernel@lists.infradead.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, Frederic Weisbecker , Ingo Molnar Subject: Re: [PATCH v8 07/26] PM / Domains: Add genpd governor for CPUs Date: Thu, 26 Jul 2018 11:14:56 +0200 Message-ID: <10360149.m4MlxDWZY5@aspire.rjw.lan> In-Reply-To: <3574880.GjmnMm1lMq@aspire.rjw.lan> References: <20180620172226.15012-1-ulf.hansson@linaro.org> <20180620172226.15012-8-ulf.hansson@linaro.org> <3574880.GjmnMm1lMq@aspire.rjw.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thursday, July 19, 2018 12:32:52 PM CEST Rafael J. Wysocki wrote: > On Wednesday, June 20, 2018 7:22:07 PM CEST Ulf Hansson wrote: > > As it's now perfectly possible that a PM domain managed by genpd contains > > devices belonging to CPUs, we should start to take into account the > > residency values for the idle states during the state selection process. > > The residency value specifies the minimum duration of time, the CPU or a > > group of CPUs, needs to spend in an idle state to not waste energy entering > > it. > > > > To deal with this, let's add a new genpd governor, pm_domain_cpu_gov, that > > may be used for a PM domain that have CPU devices attached or if the CPUs > > are attached through subdomains. > > > > The new governor computes the minimum expected idle duration time for the > > online CPUs being attached to the PM domain and its subdomains. Then in the > > state selection process, trying the deepest state first, it verifies that > > the idle duration time satisfies the state's residency value. > > > > It should be noted that, when computing the minimum expected idle duration > > time, we use the information from tick_nohz_get_next_wakeup(), to find the > > next wakeup for the related CPUs. Future wise, this may deserve to be > > improved, as there are more reasons to why a CPU may be woken up from idle. > > > > Cc: Thomas Gleixner > > Cc: Daniel Lezcano > > Cc: Lina Iyer > > Cc: Frederic Weisbecker > > Cc: Ingo Molnar > > Co-developed-by: Lina Iyer > > Signed-off-by: Ulf Hansson > > --- > > drivers/base/power/domain_governor.c | 58 ++++++++++++++++++++++++++++ > > include/linux/pm_domain.h | 2 + > > 2 files changed, 60 insertions(+) > > > > diff --git a/drivers/base/power/domain_governor.c b/drivers/base/power/domain_governor.c > > index 99896fbf18e4..1aad55719537 100644 > > --- a/drivers/base/power/domain_governor.c > > +++ b/drivers/base/power/domain_governor.c > > @@ -10,6 +10,9 @@ > > #include > > #include > > #include > > +#include > > +#include > > +#include > > > > static int dev_update_qos_constraint(struct device *dev, void *data) > > { > > @@ -245,6 +248,56 @@ static bool always_on_power_down_ok(struct dev_pm_domain *domain) > > return false; > > } > > > > +static bool cpu_power_down_ok(struct dev_pm_domain *pd) > > +{ > > + struct generic_pm_domain *genpd = pd_to_genpd(pd); > > + ktime_t domain_wakeup, cpu_wakeup; > > + s64 idle_duration_ns; > > + int cpu, i; > > + > > + if (!(genpd->flags & GENPD_FLAG_CPU_DOMAIN)) > > + return true; > > + > > + /* > > + * Find the next wakeup for any of the online CPUs within the PM domain > > + * and its subdomains. Note, we only need the genpd->cpus, as it already > > + * contains a mask of all CPUs from subdomains. > > + */ > > + domain_wakeup = ktime_set(KTIME_SEC_MAX, 0); > > + for_each_cpu_and(cpu, genpd->cpus, cpu_online_mask) { > > + cpu_wakeup = tick_nohz_get_next_wakeup(cpu); > > + if (ktime_before(cpu_wakeup, domain_wakeup)) > > + domain_wakeup = cpu_wakeup; > > + } Here's a concern I have missed before. :-/ Say, one of the CPUs you're walking here is woken up in the meantime. I don't think it is valid to evaluate tick_nohz_get_next_wakeup() for it then to update domain_wakeup. We really should just avoid the domain power off in that case at all IMO. Sure enough, if the domain power off is already started and one of the CPUs in the domain is woken up then, too bad, it will suffer the latency (but in that case the hardware should be able to help somewhat), but otherwise CPU wakeup should prevent domain power off from being carried out. Thanks, Rafael