Messages in this thread | | | From | Uladzislau Rezki <> | Date | Thu, 9 Feb 2017 19:54:05 +0100 | Subject | Re: [RFC,v2 3/3] sched: ignore task_h_load for CPU_NEWLY_IDLE |
| |
On Thu, Feb 9, 2017 at 1:22 PM, Peter Zijlstra <peterz@infradead.org> wrote: > On Wed, Feb 08, 2017 at 09:43:29AM +0100, Uladzislau Rezki wrote: >> From: Uladzislau 2 Rezki <uladzislau2.rezki@sonymobile.com> >> >> A load balancer calculates imbalance factor for particular shed >> domain and tries to steal up the prescribed amount of weighted load. >> However, a small imbalance factor would sometimes prevent us from >> stealing any tasks at all. When a CPU is newly idle, it should >> steal first task which passes a migration criteria. >>
> > So ideally we'd reduce the number of special cases instead of increase > them. > I agree.
> > Does this patch make an actual difference, if so how much and with > what workload? > Yes, it does. I see a slight improvement when it comes to frame drops (in my case drops per/two seconds). Basically a test case is left finger swipe on the display (21 times, duration is 2 seconds + 1 second sleep between iterations):
0 Framedrops: 7 5 1 Framedrops: 5 3 2 Framedrops: 8 5 3 Framedrops: 4 5 4 Framedrops: 3 3 5 Framedrops: 6 4 6 Framedrops: 3 2 7 Framedrops: 3 4 8 Framedrops: 5 3 9 Framedrops: 3 3 10 Framedrops: 7 4 11 Framedrops: 3 4 12 Framedrops: 3 3 13 Framedrops: 3 3 14 Framedrops: 3 5 15 Framedrops: 7 3 16 Framedrops: 5 3 17 Framedrops: 3 2 18 Framedrops: 5 3 19 Framedrops: 4 3 20 Framedrops: 3 2
max is 8 vs 5; min is 2 vs 3.
As for applied load, it is not significant and i would say is "light".
-- Uladzislau Rezki
| |