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

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.

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.

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."

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.

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.

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.

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.

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

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.)

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.

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.

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.

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."

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.