Hi Joonwoo,
On Fri, Oct 21, 2016 at 02:06:14PM -0700, Joonwoo Park wrote:
On 10/11/2016 05:43 PM, Leo Yan wrote:
Hi Patrick,
On Tue, Oct 11, 2016 at 05:36:46PM +0100, Patrick Bellasi wrote:
[...]
Actually, task_fits_max checks for the task fitting the _maximum_ capacity available in the system, which is tracked at root SD level. Thus, it normally checks if a task fits the 1024 (minus margin) capacity.
AFAIKS, the main difference between cpu_overutilized and misfit_task is that this last (only) considers the "boosted" task utilization.
Thus, while a small boosted task does not mark a CPU as overutilized, the same task can still be marked as a misfitting one.
I'm referring to this last point of my previous comment.
Boosted utilization does not mark a CPU overutilized, thus we should use task_misfits as well to move these tasks.
What about:
if (energy_aware) return (cpu_overutilized(cpu) || rq->misfit_task); else if (rq->nr_running >=2) return true;
I ran into same problem while I was testing upmigration latency with single CPU bound task. Above fix suggested by Patrick combined with 'sched/fair: replace capacity_of by capacity_orig_of' by Leo fixed my problem and reduced upmigration latency from ~1sec to ~250ms.
I found Patrick's fix will introduce significant IPIs for rescheduling; this is because after big core is "overutilized" then it will kick off nohz idle balance, even the big core has only one task is running. So after compared Patrick's suggestion with my v1 patch, the "Rescheduling interrupts" will increase > 50%. As a side effect, this also will harm energy by waking up CPUs.
So I prefer to go back to use v1 patch, need Patrick's reviewing if this is okay or not.
~250ms is still huge but CPU became overutilized after ~210ms of long ramp up time in my setup so it's separate problem.
The ramp up time is longer than expected, if set to highest OPP the util_avg takes 31ms to reach 50% level and takes 74ms to reach 80%: http://people.linaro.org/~leo.yan/eas_profiling/pelt/pelt_up_down_y%5e32_0.5...
So what CPUFreq governor are you using? Before I used "ondemand" governor with long smapling window (80ms), I can see similiar behaviour.
So please feel free to
Tested-by: Joonwoo Park joonwoop@codeaurora.org
Thanks for testing, will add.
Thanks, Leo Yan