Messages in this thread | | | Date | Wed, 20 Feb 2013 11:49:58 +0100 | From | Ingo Molnar <> | Subject | Re: [RFC PATCH v3 0/3] sched: simplify the select_task_rq_fair() |
| |
* Michael Wang <wangyun@linux.vnet.ibm.com> wrote:
> v3 change log: > Fix small logical issues (Thanks to Mike Galbraith). > Change the way of handling WAKE. > > This patch set is trying to simplify the select_task_rq_fair() > with schedule balance map. > > After get rid of the complex code and reorganize the logical, > pgbench show the improvement, more the clients, bigger the > improvement. > > Prev: Post: > > | db_size | clients | | tps | | tps | > +---------+---------+ +-------+ +-------+ > | 22 MB | 1 | | 10788 | | 10881 | > | 22 MB | 2 | | 21617 | | 21837 | > | 22 MB | 4 | | 41597 | | 42645 | > | 22 MB | 8 | | 54622 | | 57808 | > | 22 MB | 12 | | 50753 | | 54527 | > | 22 MB | 16 | | 50433 | | 56368 | +11.77% > | 22 MB | 24 | | 46725 | | 54319 | +16.25% > | 22 MB | 32 | | 43498 | | 54650 | +25.64% > | 7484 MB | 1 | | 7894 | | 8301 | > | 7484 MB | 2 | | 19477 | | 19622 | > | 7484 MB | 4 | | 36458 | | 38242 | > | 7484 MB | 8 | | 48423 | | 50796 | > | 7484 MB | 12 | | 46042 | | 49938 | > | 7484 MB | 16 | | 46274 | | 50507 | +9.15% > | 7484 MB | 24 | | 42583 | | 49175 | +15.48% > | 7484 MB | 32 | | 36413 | | 49148 | +34.97% > | 15 GB | 1 | | 7742 | | 7876 | > | 15 GB | 2 | | 19339 | | 19531 | > | 15 GB | 4 | | 36072 | | 37389 | > | 15 GB | 8 | | 48549 | | 50570 | > | 15 GB | 12 | | 45716 | | 49542 | > | 15 GB | 16 | | 46127 | | 49647 | +7.63% > | 15 GB | 24 | | 42539 | | 48639 | +14.34% > | 15 GB | 32 | | 36038 | | 48560 | +34.75% > > Please check the patch for more details about schedule balance map.
The changes look clean and reasoable, any ideas exactly *why* it speeds up?
I.e. are there one or two key changes in the before/after logic and scheduling patterns that you can identify as causing the speedup?
Such changes also typically have a chance to cause regressions in other workloads - when that happens we need this kind of information to be able to enact plan-B.
Thanks,
Ingo
| |