Tuesday 16 August 2011

Phoronix revisits BFS

Phoronix once benchmarked BFS in its early days. I guess at the prodding of people who suggested it here (thanks!), they've revisited it. Of course they did a throughput benchmark comparison which is kinda missing the point of BFS, but then again if they find ANY throughput benchmark where BFS is better, that's somewhere between amusing and disappointing. Anyway they did mention in passing that "However, the system with the BFS scheduler was more responsive during the test process." While this at least pays homage to what BFS really is about, it makes me wonder - what were they doing while the benchmarks ran? Benchmarks are meant to run without anything else running on the machine.

Anyway, thanks to phoronix for conducting these benchmarks and their logo suggestion.


Probably more interesting a test of something besides pure throughput is that of a server admin who was running mainline with 6000-8000 processes and his system was falling over under that load. Then he switched to BFS with no change in the usage (actually increasing) which fixed his problems. Here's the graph and see if you can guess when he switched to BFS.


  1. Another useless benchmark from Phoronix... There is no way to measure what you can feel... bfs = snappier desktop, cfs = omg am I running windoze 98 ? :P

    1. Then what you feel doesn't exist.
      Still, I look forward to trying out bfs on the 3.3 kernel.

  2. I doubt that you can tune for feel, but you can do it for latency. I also understand that average latency may not be that descriptive and the tails of the distribution must be compared. All I want is to stop using intangible arguments and have some numbers. I, of course, assume that BFS is not a religious cult.

  3. Simple fact: bfs for 3.0 has been released a few days ago, until then we had to use stock 3.0 kernel. Things like menus, video streaming lagged so bad that many of us had to go back to 2.6.39-bfs. To me that means more than "some numbers."

  4. Don't forget that latency WAS tested with BFS, with a cumulative distribution function:


  5. Don't you just love how bfs detractors repeat the same dumb arguments ad nauseam ("CK insults devs", "bfs uses 1 gazillion Hz", etc) much like the "Reiser murdered his wife" argument for reiserfs? But in the end, their loss.

  6. Hi Con,

    Thanks for your feedback.

    The benchmarks used were basically what I had time to quickly run before leaving for LinuxCon and some of what were impacted in the past when using BFS long ago.

    In terms of the responsiveness during benchmarking, all Phoronix tests are run multiple times when recording the results (in order to average the results and determine the std deviation, etc), but in the case of scheduler tests, multiole times beyond that since, yes, the focus of BFS is on the responsiveness / latency. So when repeating those unrecorded results, tasks like desktop menu browsing, web browsing, etc were used.

    If you (or anyone else) has any further questions or concerns please feel free to let me know.

    Michael Larabel

    1. This is the same thing you did with low-jitter kernel, Michael. Missing the point completely, that standard can barely run 15fps straight, and low-jitter does 72.7 accurately. With a bunch of idiots in the forum just as ignorant, attacking. You even have an article on low-jitter mutter with Wayland. Have you even any idea what you are typing?

      The rest of you can try my low-jitter kernel, and compare to CFS, or even the windows XP low-jitter tweak there. And no "windows" is not slow on most stuff. But Linux with low-jitter is faster. And on very jitter sensitive games, such as Doom 3, which does 3 passes to OpenGL, (pr frame), A core2duo with GTX280 plays it perfectly, while that requires a modern E5 workstation on Windows. That is a 5 year lead. However also on the E5, things in practise are much less different.

      BFS in my tests lost out to CFS, on general usage.


      And there is a lot of ignorant people who will not understand this online, but I guess BFS interested people, are le people of low jitter, and will understand :) Actually CFS people would be too, since it seems better. "Fairness" being something actually relevant, and not just a gimmick.

      Peace Be With You.

  7. I'd like to see BFS tailored towards improving the 3D gaming experience, is that even possible? My Gentoo system is always much more responsive with BFS, so thanks for all your hard work Con. A lot of people admire and respect your attitude plus skill in programming, we need more thinkers like you in the world, lol :D Live long and prosper! :P

    1. Check post above. Extremely good for games.

  8. Is this useful https://perf.wiki.kernel.org/ ?

  9. Would someone care to explain how somebody like Con-man Kolivas who goes out of his way to burn bridges and insult players... still manages to get press releases?

  10. Are you going to copy&paste this verbatim in more places for the rest of the day, or something? It gets boring reading the same troll over and over again.

  11. if you want that for a logo I can make it into a vector for you. I wouldn't mind seeing that every time I boot the kernel lol

  12. could you share which distros ship with bfs or have it in their repos? Many of us would love to test it without manually patching kernels I am sure =)

  13. AFAIK, PCLinuxOS and Zenwalk use BFS by default. Also any debian-based distro (Ubuntu, etc.) can install the deb files from liquorix.net where you can find a kernel compiled with zen patches, which also include bfs (not a good choice if you want to compare to the stock kernel, since zen include lots of different patches, not just ck.)

  14. @anon - a vector logo of the graffiti would be killer! I think the kernel standard is 80x80 no? Anyway, if you do put something together, post a url to d/l it in this blog entry :)

  15. Even if the tests don't measured the main intention of BFS, it has something to say:

    How bad is CFS.
    As BFS takes double efforts to minimize latency, the concurrent scheduler CFS should have better results for every subtest in throughput not just in the apache case.

    Isn't this worth a bug at kernel.org? I mean just like the power issue phoronix found recently: There is large empty space up in front of CFS to improve.

    The mesured power consumption of all these tests indicate BFS is running 7% longer on battery powered devices ...

  16. Uuh, my bad english, sorry for that above.
    I hope every one understands what I want to say:

    After years of development CFS is not near reaching theoretical optimum. Which should be worth a bug ...

  17. These benchmarks seem to miss the point of BFS. I think a much better comparison would be to take a bunch of first person shooter gamers and have them play Xonotic for five minutes each on two identical, with the following exception, computers. One computer would be using the unpatched kernel with the CFS scheduler with Xonotic running and nothing running in the background. The other computer would have the ck patched kernel with the BFS scheduler with Xonotic running and having one lrzip process per core compress some large files in the background. After each gamer has played on each system, ask which one had stuff running in the background and see how many of them guess incorrectly. I bet they would have a really difficult time trying figure that out and many would guess incorrectly. Sometimes when I have a large application or kernel compiling in the background, I will start up a game, and when I quit the game and see the terminal window, I realize that I completely forgot I was compiling something.

    By the way, congratulations on having what must be the Phronix article with the highest usage of foul language and most disturbing grapheaty benchmarking the BFS scheduler.

  18. Real contributers (Con, Ingo, and Michael included) try to solve problems. Lusers whine about one contributer or the other does based on an incomplete (and usually incorrect) understanding of the problem space while providing no real value. Con got wronged when Ingo essential took the findings of Con's research and development to re-implement the CPU scheduler himself and used his established position to get his solution accepted by Linus. Obviously this pissed off Con which is too bad since his contributions were obviously valuable (remember ConTest). The best way forward is to positively leverage the research efforts of people like Con and Michael to identify, quantify, and solve system behavior problems, and then present the results to LKML where people like Ingo will incorporate or redesign solutions for inclusion in the kernel.

  19. @Anonymous, your implicitly say:

    There is one scheduler possible reaching optimum for every task on every hardware. All we need is research to find this wonder algo!

    I don't believe this. But as long as all of kernel.org developers think like you, there should be a bug open stating CFS should have much better throughput performance than a scheduler taking care of latency.

  20. Ralph Ulrich: "Isn't this worth a bug at kernel.org? I mean just like the power issue phoronix found recently: There is large empty space up in front of CFS to improve."

    Well, judging from efficiency of cfs & slub on non-numa machines, and from how long it takes for power-related bugs to get fixed, apparently Linux devs are not interested in resolving power issues, better response, etc. Phoronix just found a new regression in 3.1. According to benchmarks in the article,

    "The Linux 2.6.38 kernel had an average power consumption of 13.2 Watts, Linux 2.6.39 was at 13.9 Watts, Linux 3.0 up to 17.3 Watts, and the Linux 3.1 kernel Git is now at 22.8 Watts."

    Nice huh?

  21. Actually their software does not have a bug, it is the bug :(

  22. >> Ren said...
    >> AFAIK, PCLinuxOS and Zenwalk use BFS by default.

    Ren, thank you for the tip. (The Anon asking for distros bundling BFS)

  23. I actually noticed a big increase in performance while playing games on a dual core athlon 5000+ system and a 9600GSO graphics card. Not that my framerate really went up all to much, it was just that the game was lagging from time to time all the way down to 10 fps no matter what settings I used... even though the avg framerate would be about 60+ BFS solved this and I was plesently supprised how well it's been working.

  24. Sorry if I post at the wrong place but I did not find any other place where my post would appear less off-topic.

    Its is about Interbench-0.31 ran as advised, that is to say in single user mode on my Intel core II duo system running a stock 2.6.38 kernel.

    interbench -r produces results such as for rt-audio :

    None 24.0 +/- 24.4 31.0 100 100
    Video 9.0 +/- 10.1 20.0 100 100
    X 16.0 +/- 17.2 27.0 100 100
    Burn 4.0 +/- 4.6 6.0 100 100

    1/ How can I get greater latencies with an "otherwise idle system" than with a system loaded with miscellaneous simulation threads ?

    2/ How can I get a maximum latency < average + SD ?