Messages in this thread | | | Date | Thu, 28 May 2015 13:53:39 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH] sched: prefer an idle cpu vs an idle sibling for BALANCE_WAKE |
| |
* Josef Bacik <jbacik@fb.com> wrote:
> On 05/26/2015 05:31 PM, Josef Bacik wrote: > >At Facebook we have a pretty heavily multi-threaded application that is > >sensitive to latency. We have been pulling forward the old SD_WAKE_IDLE code > >because it gives us a pretty significant performance gain (like 20%). It turns > >out this is because there are cases where the scheduler puts our task on a busy > >CPU when there are idle CPU's in the system. We verify this by reading the > >cpu_delay_req_avg_us from the scheduler netlink stuff. With our crappy patch we > >get much lower numbers vs baseline. > > > >SD_BALANCE_WAKE is supposed to find us an idle cpu to run on, however it is just > >looking for an idle sibling, preferring affinity over all else. This is not > >helpful in all cases, and SD_BALANCE_WAKE's job is to find us an idle cpu, not > >garuntee affinity. Fix this by first trying to find an idle sibling, and then > >if the cpu is not idle fall through to the logic to find an idle cpu. With this > >patch we get slightly better performance than with our forward port of > >SD_WAKE_IDLE. Thanks, > > > > I rigged up a test script to run the perf bench sched tests and give me the > numbers. Here are the numbers > > 4.0 > > Messaging: 56.934 Total runtime in seconds > Pipe: 105620.762 ops/sec > > 4.0 + my patch > > Messaging: 47.374 > Pipe: 113691.199
Btw., with perf bench you don't really need much extra scripting, something like this should give you pretty good numbers plus an stddev estimate:
perf stat --null --repeat 10 perf bench sched messaging -l 10000
on my box this gives:
4.391469643 seconds time elapsed ( +- 2.81% )
you can adjust the -l value to move the runtime up/down to a value that you think runs long enough to give stable results.
Thanks,
Ingo
| |