[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <119031115.C8gHTGbYmQ@aspire.rjw.lan>
Date: Fri, 11 Jan 2019 12:06:15 +0100
From: "Rafael J. Wysocki" <rjw@...ysocki.net>
To: Ulf Hansson <ulf.hansson@...aro.org>
Cc: Sudeep Holla <sudeep.holla@....com>,
Lorenzo Pieralisi <Lorenzo.Pieralisi@....com>,
Mark Rutland <mark.rutland@....com>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
linux-pm@...r.kernel.org,
"Raju P . L . S . S . S . N" <rplsssn@...eaurora.org>,
Stephen Boyd <sboyd@...nel.org>,
Tony Lindgren <tony@...mide.com>,
Kevin Hilman <khilman@...nel.org>,
Lina Iyer <ilina@...eaurora.org>,
Viresh Kumar <viresh.kumar@...aro.org>,
Vincent Guittot <vincent.guittot@...aro.org>,
Geert Uytterhoeven <geert+renesas@...der.be>,
linux-arm-kernel@...ts.infradead.org,
linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
Lina Iyer <lina.iyer@...aro.org>,
Thomas Gleixner <tglx@...utronix.de>,
Frederic Weisbecker <fweisbec@...il.com>,
Ingo Molnar <mingo@...nel.org>
Subject: Re: [PATCH v10 03/27] timer: Export next wakeup time of a CPU
On Thursday, November 29, 2018 6:46:36 PM CET Ulf Hansson wrote:
> From: Lina Iyer <lina.iyer@...aro.org>
>
> 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 <tglx@...utronix.de>
> Cc: Daniel Lezcano <daniel.lezcano@...aro.org>
> Cc: Lina Iyer <ilina@...eaurora.org>
> Cc: Frederic Weisbecker <fweisbec@...il.com>
> Cc: Ingo Molnar <mingo@...nel.org>
> Signed-off-by: Lina Iyer <lina.iyer@...aro.org>
> Co-developed-by: Ulf Hansson <ulf.hansson@...aro.org>
> Signed-off-by: Ulf Hansson <ulf.hansson@...aro.org>
> ---
>
> 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.
Powered by blists - more mailing lists