Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1577873
| From | Uladzislau Rezki <urezki@gmail.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC,v2 3/3] sched: ignore task_h_load for CPU_NEWLY_IDLE |
| Date | 2017-02-09 20:10 +0100 |
| Message-ID | <t92gq-1CS-19@gated-at.bofh.it> (permalink) |
| References | <t8wgy-6w4-11@gated-at.bofh.it> <t8wgz-6w4-29@gated-at.bofh.it> <t8W1l-66e-37@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[RFC,v2 1/3] sched: set loop_max after rq lock is taken Uladzislau Rezki <urezki@gmail.com> - 2017-02-08 10:00 +0100
[RFC,v2 3/3] sched: ignore task_h_load for CPU_NEWLY_IDLE Uladzislau Rezki <urezki@gmail.com> - 2017-02-08 10:00 +0100
Re: [RFC,v2 3/3] sched: ignore task_h_load for CPU_NEWLY_IDLE Mike Galbraith <efault@gmx.de> - 2017-02-08 10:50 +0100
Re: [RFC,v2 3/3] sched: ignore task_h_load for CPU_NEWLY_IDLE Uladzislau Rezki <urezki@gmail.com> - 2017-02-09 11:20 +0100
Re: [RFC,v2 3/3] sched: ignore task_h_load for CPU_NEWLY_IDLE Peter Zijlstra <peterz@infradead.org> - 2017-02-09 13:30 +0100
Re: [RFC,v2 3/3] sched: ignore task_h_load for CPU_NEWLY_IDLE Uladzislau Rezki <urezki@gmail.com> - 2017-02-09 20:10 +0100
Re: [RFC,v2 3/3] sched: ignore task_h_load for CPU_NEWLY_IDLE Peter Zijlstra <peterz@infradead.org> - 2017-02-13 15:00 +0100
Re: [RFC,v2 3/3] sched: ignore task_h_load for CPU_NEWLY_IDLE Uladzislau Rezki <urezki@gmail.com> - 2017-02-13 18:20 +0100
Re: [RFC,v2 1/3] sched: set loop_max after rq lock is taken Peter Zijlstra <peterz@infradead.org> - 2017-02-09 14:40 +0100
csiph-web