Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp453417imm; Fri, 12 Oct 2018 00:44:23 -0700 (PDT) X-Google-Smtp-Source: ACcGV62/iCGiTyzvwMRb38Ns+0Js/ZkauuIKjnjuCUL6lykXCX/Bb9keOpnEKIn3kdBI//6elM2+ X-Received: by 2002:a63:c84c:: with SMTP id l12-v6mr4452481pgi.77.1539330263938; Fri, 12 Oct 2018 00:44:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539330263; cv=none; d=google.com; s=arc-20160816; b=DrlfhNQeUL/VeLPzTSc6RchqIyO1QsW3U5UsTkVUDFhBGDBB6Zn2sRNEVT47CQlnl/ fPfdS34zPNPYVw62nUOu8Qq5U/nJrTDEo/zz/Ln9XRYHcERnlnjyZdD28EOxvfNJnzQO +WvDof9yEAdb/7mz2sU79pMcshi6TCHL/W/E1Hjqj0nE3x0M+1j1vVT8Jqlky/EW4OLl T/Ol5HdsZk/0rWGe0mp2Q7Jax5r5bI4Gyqd/9WEUdh4q3VUXWyexw+MKC6CTNSjhuzp/ wPD0DtHzmeziCnxrT0z9fyratnC2TALdHAWOHjNp7zX2RTelM3zb4Be8xMg53mpeO/Q7 L1eA== 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; bh=2N6LmD7zHSnSP1dXyQSLFqpAnslerYQmmZyfMbCCiAc=; b=rLJJIPGj4fpDI3On2JSDPzldjCJTCnGgr1pDtlOuZErKsmV9gIEFDbox0hWnBmSIr6 3JhGGwq8/UfQVYyo1RH7XphLSbcKwlLOzE/+6GA3oisHOevQ92wXtIGJJ6+ooHVKBHz8 dwt53/vf4KC+fuHNQkOtkOmj+Uu1OFGIz42GJkL9O/KjOOpaVzqBCKIF48ABl0Xofq42 idvzbPrLZEUOeFr8JQn/6Hm5RTmIh0Z5QaNsSE2lUd43lcj55ju+VD75GpbuodaJlNC1 h8PFR8FLsISnX8o71H49mCcRDXrPQOrDFowxCBmqkAH9ckCuMly7K5J1WHT7olIGc38D TlwQ== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d38-v6si447748pla.422.2018.10.12.00.44.07; Fri, 12 Oct 2018 00:44:23 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727605AbeJLPOz (ORCPT + 99 others); Fri, 12 Oct 2018 11:14:55 -0400 Received: from mail-oi1-f194.google.com ([209.85.167.194]:44916 "EHLO mail-oi1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726761AbeJLPOz (ORCPT ); Fri, 12 Oct 2018 11:14:55 -0400 Received: by mail-oi1-f194.google.com with SMTP id u74-v6so9165596oia.11; Fri, 12 Oct 2018 00:43:45 -0700 (PDT) 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=2N6LmD7zHSnSP1dXyQSLFqpAnslerYQmmZyfMbCCiAc=; b=rv1cHYyFv+mVfQY8MioRciQ3Yldw2J87222CqGhg8Q6RRJY0XudxFnaijerznTgJEZ m2IGzC9bOdSuBcJQe2nThNDSQQ9dq21N1iVsRgAM8gJDp3Ou0wsQ1oyYqUmeYT2SEgPK f9s7mNXpWxWPFI1va6OMBO8wsAPmlTg4bjK4RI8awWNxDMb9V49VJXbfXBNirfFeuknj 5oAthryUBX3vIbn2Qa+YlnPsel254+P5i57en4pVxwoCHMSUePalweTbK4QMsC9yqHzf P4Nxa981/1XF7D7SDnnJhMxmRRhFs1OJpewxgTao5e1xT4dmV0RDQnr0ljxC/EfSlVJA wfBQ== X-Gm-Message-State: ABuFfohfgv8YvXSe6+1FO5x6ayncZz+Rm8Im+QcXQwOSoADZGhn7mGxr ytm3IJkq/8twIIrgW1WAx5ht3Zji5HzWR0TcJcg= X-Received: by 2002:aca:b655:: with SMTP id g82-v6mr2509982oif.195.1539330224708; Fri, 12 Oct 2018 00:43:44 -0700 (PDT) MIME-Version: 1.0 References: <1539206455-29342-1-git-send-email-rplsssn@codeaurora.org> <1539206455-29342-3-git-send-email-rplsssn@codeaurora.org> <8161939.SRDo8Qx48D@aspire.rjw.lan> <20181011220842.GE2371@codeaurora.org> In-Reply-To: <20181011220842.GE2371@codeaurora.org> From: "Rafael J. Wysocki" Date: Fri, 12 Oct 2018 09:43:31 +0200 Message-ID: Subject: Re: [PATCH RFC v1 2/8] kernel/cpu_pm: Manage runtime PM in the idle path for CPUs To: Lina Iyer Cc: "Rafael J. Wysocki" , rplsssn@codeaurora.org, Andy Gross , david.brown@linaro.org, Ulf Hansson , Kevin Hilman , linux-arm-msm , linux-soc@vger.kernel.org, "Nayak, Rajendra" , bjorn.andersson@linaro.org, Linux Kernel Mailing List , Linux PM , "devicetree@vger.kernel.org" , Stephen Boyd , evgreen@chromium.org, Doug Anderson , Matthias Kaehlcke 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 Fri, Oct 12, 2018 at 12:08 AM Lina Iyer wrote: > > On Thu, Oct 11 2018 at 14:56 -0600, Rafael J. Wysocki wrote: > >On Wednesday, October 10, 2018 11:20:49 PM CEST Raju P.L.S.S.S.N wrote: > >> From: Ulf Hansson > >> > >> To allow CPUs being power managed by PM domains, let's deploy support for > >> runtime PM for the CPU's corresponding struct device. > >> > >> More precisely, at the point when the CPU is about to enter an idle state, > >> decrease the runtime PM usage count for its corresponding struct device, > >> via calling pm_runtime_put_sync_suspend(). Then, at the point when the CPU > >> resumes from idle, let's increase the runtime PM usage count, via calling > >> pm_runtime_get_sync(). > >> > >> Cc: Lina Iyer > >> Co-developed-by: Lina Iyer > >> Signed-off-by: Ulf Hansson > >> Signed-off-by: Raju P.L.S.S.S.N > >> (am from https://patchwork.kernel.org/patch/10478153/) > >> --- > >> kernel/cpu_pm.c | 11 +++++++++++ > >> 1 file changed, 11 insertions(+) > >> > >> diff --git a/kernel/cpu_pm.c b/kernel/cpu_pm.c > >> index 67b02e1..492d4a8 100644 > >> --- a/kernel/cpu_pm.c > >> +++ b/kernel/cpu_pm.c > >> @@ -16,9 +16,11 @@ > >> */ > >> > >> #include > >> +#include > >> #include > >> #include > >> #include > >> +#include > >> #include > >> #include > >> > >> @@ -91,6 +93,7 @@ int cpu_pm_enter(void) > >> { > >> int nr_calls; > >> int ret = 0; > >> + struct device *dev = get_cpu_device(smp_processor_id()); > >> > >> ret = cpu_pm_notify(CPU_PM_ENTER, -1, &nr_calls); > >> if (ret) > >> @@ -100,6 +103,9 @@ int cpu_pm_enter(void) > >> */ > >> cpu_pm_notify(CPU_PM_ENTER_FAILED, nr_calls - 1, NULL); > >> > >> + if (!ret && dev && dev->pm_domain) > >> + pm_runtime_put_sync_suspend(dev); > > > >This may cause a power domain to go off, but if it goes off, then the idle > >governor has already selected idle states for all of the CPUs in that domain. > > > >Is there any way to ensure that turning the domain off (and later on) will > >no cause the target residency and exit latency expectations for those idle > >states to be exceeded? > > > Good point. > > The cluster states should account for that additional latency. But even then, you need to be sure that the idle governor selected "cluster" states for all of the CPUs in the cluster. It might select WFI for one of them for reasons unrelated to the distance to the next timer (so to speak), for example. > Just the CPU's power down states need not care about that. The meaning of this sentence isn't particularly clear to me. :-) > But, it would be nice if the PM domain governor could be cognizant of > the idle state chosen for each CPU, that way we dont configure the > domain to be powered off when the CPUs have just chosen to power down > (not chosen a cluster state). I think that is a whole different topic to > discuss. This needs to be sorted out before the approach becomes viable, though. Basically, the domain governor needs to track what the idle governor did for all of the CPUs in the domain and only let the domain go off if the latency matches all of the states selected by the idle governor. Otherwise the idle governor's assumptions would be violated and it would become essentially useless overhead. Thanks, Rafael