[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160309123539.GL6356@twins.programming.kicks-ass.net>
Date: Wed, 9 Mar 2016 13:35:39 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: "Rafael J. Wysocki" <rjw@...ysocki.net>
Cc: Linux PM list <linux-pm@...r.kernel.org>,
Ingo Molnar <mingo@...nel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
Viresh Kumar <viresh.kumar@...aro.org>,
Juri Lelli <juri.lelli@....com>,
Steve Muckle <steve.muckle@...aro.org>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH v10 1/3] cpufreq: Add mechanism for registering
utilization update callbacks
On Mon, Feb 15, 2016 at 10:47:22PM +0100, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
>
> Introduce a mechanism by which parts of the cpufreq subsystem
> ("setpolicy" drivers or the core) can register callbacks to be
> executed from cpufreq_update_util() which is invoked by the
> scheduler's update_load_avg() on CPU utilization changes.
>
> This allows the "setpolicy" drivers to dispense with their timers
> and do all of the computations they need and frequency/voltage
> adjustments in the update_load_avg() code path, among other things.
>
> The update_load_avg() changes were suggested by Peter Zijlstra.
>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> Acked-by: Viresh Kumar <viresh.kumar@...aro.org>
> ---
> drivers/cpufreq/cpufreq.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
> include/linux/cpufreq.h | 34 ++++++++++++++++++++++++++++++++++
> kernel/sched/deadline.c | 4 ++++
> kernel/sched/fair.c | 26 +++++++++++++++++++++++++-
> kernel/sched/rt.c | 4 ++++
> kernel/sched/sched.h | 1 +
> 6 files changed, 113 insertions(+), 1 deletion(-)
>
So with the understanding that we'll work on getting rid of
cpufreq_trigger_update().
Acked-by: Peter Zijlstra (Intel) <peterz@...radead.org>
Also, Vincent had some concerns about the exact placement of the
callback, and I see no problem in moving it if there's need.
Powered by blists - more mailing lists