On 10/22/2016 07:45 AM, Leo Yan wrote:
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.
Okay. I haven't yet tried your original patch. I happened to make this fix below and it addressed my test case and found Patrick's suggestion and confirmed it also did same job.
if (rq->nr_running >= 2 && !energy_aware()) return true;
if (energy_aware() && cpu_overutilized(cpu)) return true;
Looking at your original patch again. I'm bit worried upmigration latency delay since misfit_task will be set by scheduler tick path if there is 1 cpu bound task running without new wake up. I will see how Patrick thinks about and do another test.
~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...
This is with upstream pelt delacying factor? Interestingly I even have pelt half lift change running and having longer rampup time. So mine should have ramped even faster than yours.
So what CPUFreq governor are you using? Before I used "ondemand" governor with long smapling window (80ms), I can see similiar behaviour.
I'm using sched-freq.
Thanks, Joonwoo
So please feel free to
Tested-by: Joonwoo Park joonwoop@codeaurora.org
Thanks for testing, will add.
Thanks, Leo Yan