On Wed, Jun 7, 2017 at 5:43 PM, Morten Rasmussen morten.rasmussen@arm.com wrote:
On Wed, Jun 07, 2017 at 05:36:55PM +0530, Viresh Kumar wrote:
- Patrick,
On 01-06-17, 14:22, Peter Zijlstra wrote:
On Thu, Jun 01, 2017 at 05:04:27PM +0530, Viresh Kumar wrote:
This patch relocates the call to utilization hook from update_cfs_rq_load_avg() to task_tick_fair().
That's not right. Consider hardware where 'setting' the DVFS is a 'cheap' MSR write, doing that once every 10ms (HZ=100) is absurd.
Yeah, that may be too much for such a platforms. Actually we (/me & Vincent) were worried about the current location of the utilization update hooks and believed that they are getting called way too often. But yeah, this patch optimized it way too much.
One of the goals of this patch was to avoid doing small OPP updates from update_load_avg() which can potentially block significant utilization changes (and hence big OPP changes) while a task is attached or detached, etc.
To me that sounds like you want to apply a more clever filter to the utilization updates than a simple rate limiter as Peter suggests below. IMHO, it would be better to feed schedutil with all the available information and improve the filtering policy there instead of trying to hack the policy tweaking the input data.
Agreed.
Unless the tweaked input data would be used somewhere else too, that is.
We spoke about this problem in Pisa, the proposed solution was having each driver provide a cost metric and the generic code doing a max filter over the window constructed from that cost metric.
Maybe it is possible to somehow let the rate at which we allow OPP changes depend on the size of the 'error' delta between the current OPP and what we need. So radical changes causes OPP changes immediately, and small corrections have to wait longer?
That sounds reasonable to me.
Thanks, Rafael