On 26-07-17, 23:23, Joel Fernandes (Google) wrote:
Ok, but the "heavy" in init_entity_runnable_average means for load, not the util_avg. The util_avg is what's used for frequency scaling IIUC and is set to 0 in that function no?
That's because the task isn't enqueued yet and so don't have any utilization. The last line of that routine is a comment which says:
/* when this task enqueue'ed, it will contribute to its cfs_rq's load_avg */
But once the task is enqueued, this load_avg will get considered for sure :)
The application was written by Steve (all credit goes to him) before he left Linaro, but I did test it with ftrace. What I saw with ftrace was that the freq isn't reevaluated for almost an entire tick many times because we enqueued the task remotely. And that changes with this series.
The reason being that this patchset only targets a corner case, where following are required to be true to improve performance and that doesn't happen too often with these tests:
- Task is migrated to another CPU.
- The task has maximum demand initially, and should take the CPU to
Just to make the cover-letter more clear and also confirming with you I understand the above usecase, maybe in the future this can reworded from "initially" to "before the migration" and "take the CPU" to "take the target CPU of the migration" ?
I can reword it a bit, but the test case wasn't really migrating anything and was looking only at the initial loads.
Ok, I wasn't talking about the synthetic test in the second part of my email above but about the explanation you gave about Galleryfling improvement (that the migration of a task with high utilization doesn't update the target frequency) which makes sense to me so we are on the same page about that.
Okay, great.
-- viresh