Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp617913imu; Fri, 11 Jan 2019 06:17:25 -0800 (PST) X-Google-Smtp-Source: ALg8bN7+NK7dLcYLEB7QlPwOWZ0/biPSbitsj7WvuSs6+oApHRY7fqoFC8PCK86WM19buwMAOaJr X-Received: by 2002:a62:7892:: with SMTP id t140mr14699200pfc.237.1547216244953; Fri, 11 Jan 2019 06:17:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547216244; cv=none; d=google.com; s=arc-20160816; b=H/gBWHXSdPF96mTCSTQr6x1wv+S5vTX4VmnpGJU4OQy4/HqcqFG6FYoALYDiqg57Na q9f5ESZ1N9w95N+1cdsjlnATmbSyo4VoPiFwzs7WGz7G0SAkfryJetctfp+vUADPWZAk bsv/Ir9/9iVVgOxFcr0SHkh1BBg2gVMhs7++zmMAxJAufURynWiNxH59AvAOANw3XMCp JcaHwQsczRADXtOWaa/rNh25SOInwS6gH8KUPhJEM2LJdcO5DfTanuT6ve/gwVLw0F0F MgAvVH1FvpdSNg0VXjS1ri7SqWEFIPGgKFRa1SWXFxa1T5iSF0QhiJAWyXPMhpstNABF pgYg== 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; bh=G9mcNBWnM+qoE6sZsXUn8/8y7MN1xtCa+0m4wt+P+lg=; b=FYuz7B6YcusZnNjfnwtsdbh2U4Z74tcok5zDzCS+DL2Yl1G6VYvnKtUhg5Fw+FNi1I m0tx9zPXanUl0oRLVBkMXUiGKu9smiRxZs1gQMqvOpygqPgWpJSSMCpsfz5ue26nvIxT w0QEmpPIHRCf3mG/Vh/LigUzpL8OCwYkgHKMnBXYNmvDO6MfZpuXsSLm7L37pmUS5zg6 /Lzz2HK0pFeR7MM5BKuQqf0jWGgHtieXKx8YpWi1/m5U0yXRd5pbgYqo1x0aLRZ/dcbE Y8ySaKy1Z2qNvugXrt0IGHtzZonctO+OuQodwZaPmG1meWr8hIrIKJBX3SiVi9VIHfB+ hfiQ== 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 q2si9095635plh.261.2019.01.11.06.17.09; Fri, 11 Jan 2019 06:17:24 -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; 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 S1731378AbfAKLHH (ORCPT + 99 others); Fri, 11 Jan 2019 06:07:07 -0500 Received: from cloudserver094114.home.pl ([79.96.170.134]:55766 "EHLO cloudserver094114.home.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725780AbfAKLHF (ORCPT ); Fri, 11 Jan 2019 06:07:05 -0500 Received: from 79.184.254.168.ipv4.supernova.orange.pl (79.184.254.168) (HELO aspire.rjw.lan) by serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer 0.83.183) id 87e8267296bcc0e4; Fri, 11 Jan 2019 12:07:02 +0100 From: "Rafael J. Wysocki" To: Ulf Hansson Cc: Sudeep Holla , Lorenzo Pieralisi , Mark Rutland , Daniel Lezcano , linux-pm@vger.kernel.org, "Raju P . L . S . S . S . N" , Stephen Boyd , Tony Lindgren , Kevin Hilman , Lina Iyer , Viresh Kumar , Vincent Guittot , Geert Uytterhoeven , linux-arm-kernel@lists.infradead.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, Lina Iyer , Thomas Gleixner , Frederic Weisbecker , Ingo Molnar Subject: Re: [PATCH v10 03/27] timer: Export next wakeup time of a CPU Date: Fri, 11 Jan 2019 12:06:15 +0100 Message-ID: <119031115.C8gHTGbYmQ@aspire.rjw.lan> In-Reply-To: <20181129174700.16585-4-ulf.hansson@linaro.org> References: <20181129174700.16585-1-ulf.hansson@linaro.org> <20181129174700.16585-4-ulf.hansson@linaro.org> 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, November 29, 2018 6:46:36 PM CET Ulf Hansson wrote: > From: Lina Iyer > > Knowing the sleep duration of CPUs, is known to be needed while selecting > the most energy efficient idle state for a CPU or a group of CPUs. > > However, to be able to compute the sleep duration, we need to know at what > time the next expected wakeup is for the CPU. Therefore, let's export this > information via a new function, tick_nohz_get_next_wakeup(). Following > changes make use of it. > > Cc: Thomas Gleixner > Cc: Daniel Lezcano > Cc: Lina Iyer > Cc: Frederic Weisbecker > Cc: Ingo Molnar > Signed-off-by: Lina Iyer > Co-developed-by: Ulf Hansson > Signed-off-by: Ulf Hansson > --- > > Changes in v10: > - Updated function header of tick_nohz_get_next_wakeup(). > > --- > include/linux/tick.h | 8 ++++++++ > kernel/time/tick-sched.c | 13 +++++++++++++ > 2 files changed, 21 insertions(+) > > diff --git a/include/linux/tick.h b/include/linux/tick.h > index 55388ab45fd4..e48f6b26b425 100644 > --- a/include/linux/tick.h > +++ b/include/linux/tick.h > @@ -125,6 +125,7 @@ extern bool tick_nohz_idle_got_tick(void); > extern ktime_t tick_nohz_get_sleep_length(ktime_t *delta_next); > extern unsigned long tick_nohz_get_idle_calls(void); > extern unsigned long tick_nohz_get_idle_calls_cpu(int cpu); > +extern ktime_t tick_nohz_get_next_wakeup(int cpu); > extern u64 get_cpu_idle_time_us(int cpu, u64 *last_update_time); > extern u64 get_cpu_iowait_time_us(int cpu, u64 *last_update_time); > > @@ -151,6 +152,13 @@ static inline ktime_t tick_nohz_get_sleep_length(ktime_t *delta_next) > *delta_next = TICK_NSEC; > return *delta_next; > } > + > +static inline ktime_t tick_nohz_get_next_wakeup(int cpu) > +{ > + /* Next wake up is the tick period, assume it starts now */ > + return ktime_add(ktime_get(), TICK_NSEC); > +} > + > static inline u64 get_cpu_idle_time_us(int cpu, u64 *unused) { return -1; } > static inline u64 get_cpu_iowait_time_us(int cpu, u64 *unused) { return -1; } > > diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c > index 69e673b88474..7a9166506503 100644 > --- a/kernel/time/tick-sched.c > +++ b/kernel/time/tick-sched.c > @@ -1089,6 +1089,19 @@ unsigned long tick_nohz_get_idle_calls(void) > return ts->idle_calls; > } > > +/** > + * tick_nohz_get_next_wakeup - return the next wake up of the CPU > + * @cpu: the particular CPU to get next wake up for > + * > + * Called for idle CPUs only. > + */ > +ktime_t tick_nohz_get_next_wakeup(int cpu) > +{ > + struct clock_event_device *dev = per_cpu(tick_cpu_device.evtdev, cpu); > + > + return dev->next_event; > +} > + > static void tick_nohz_account_idle_ticks(struct tick_sched *ts) > { > #ifndef CONFIG_VIRT_CPU_ACCOUNTING_NATIVE > Well, I have concerns regarding this one. I don't believe it is valid to call this new function for non-idle CPUs and the kerneldoc kind of says so, but the next patch doesn't actually prevent it from being called for a non-idle CPU (at the time it is called in there the target CPU may not be idle any more AFAICS). In principle, the cpuidle core can store this value, say in struct cpuidle_device of the given CPU, and expose a helper to access it from genpd, but that would be extra overhead totally unnecessary on everthing that doesn't use genpd for cpuidle. So maybe the driver could store it in its ->enter callback? After all, the driver knows that genpd is going to be used later.