A development blog of what Con Kolivas is doing with code at the moment with the emphasis on linux kernel, BFS and -ck.

Thursday, 7 April 2011

BFS 0.376 test

TL;DR: Fastest BFS yet for SMP.

After extended testing on BFS 0.373, a number of minor issues came up, but the results were very promising. Now I believed I've addressed all the known issues with a newer version. Instead of flagging scaling CPUs by their governor alone, I now flag them as scaling only when they're actually throttled from maximum speed. This improves throughput further with the dynamic scaling governors like ondemand and brings it now very close to that of performance under full load. I also found that the sticky flagged tasks were not keeping their sticky flags if they were rescheduled back to back. This gave me even more of a performance boost under all situations. I addressed the oops that can occur on UP, and finally I updated the docs to match the changes in the scheduler design.

So hopefully this will be the last test patch (fingers crossed) before I make it official, because... I'm about >< close to burnout. That's not something I want to experience.
Incremental for those on BFS 363 already:
bfs363-376-test.patch

Great job, CK! BFS v0.376 slightly out preforms v0.363 in my x264 tests. The results are darn close to a statistically significant margin by the way. As always, both versions of BFS are faster than the corresponding mainline scheduler by 2.6 % and 3.0 % respectively.

Excellent, thank you very much everyone for your testing and feedback. It made a massive difference to making sure I tackled all the issues. I'm hoping this release can go gold over the weekend as version 0.4. If I may, graysky, could I post those very pretty graphs on my BFS page?

In x264 encoding, both bfs versions (0.363 and 0.376) beat the mainline scheduler hands down.For compiling though, and interestingly enough, when my quad core CPU compiled filezilla-3.4.0, using make -j4, the latest bfs clearly beat both its predecessor and mainline; however, adding the extra thread to mainline (make -j5) brought it statistically in-line with bfs v0.376 for total compile time. Dunno what to make of that.

Ralph that's a very good comment. SSB who has performed many of the benchmarks to date, is compiling some meaningful benchmarks in this area and I will post them as they come to hand. http://ck.kolivas.org/patches/bfs/test/wakeup-latency.cIs a latency testing benchmark that he has run under various conditions with these different kernels and different throughput benchmarks at the same time. The results will be available soon, but suffice to say they're reassuring. Note also that absolute wake-up latency isn't the whole picture, since it will be wakeup-and-achieving-work that matters, but the two are intimately related.