Two Years With Linux BFS, The Brain Fuck Scheduler

[kraftman]

tales from the future

That's not the problem. The problem is that it's not even 1Hz more. Not even 1! And yet he runs around with his "1 million Hz" BS. So no, it's not "a hole lot of hz." It's exactly the same as without BFS.

He just makes me wanna shoot bunnies every time he posts.

It's your fault you've got problems with the things I didn't say, so stop your imaginary bullshit. You have no problems in blaming Linux overall, but you can't stand someone can blame your lovely BFS (what's more funny I didn't even blame it here). Next time when you'll give me some advices begin from yourself. When Con posts stupid patches like 10kHz (ten times more than standard) then it's hard to take sersiously something called brain f*uck scheduler. Someone said interesting thing about BFS thoroughput which was very good in Phoronix benchmarks as a proof it introduces better latency (which wasn't measured) with no cost in thoroughput. It can be like this, but the risky 10kHz patch I mentioned before can make some people wonder if there aren't downsides in other areas like safety etc. Just speculation, but not unfounded.

[elias1884]

CK delivered an unmatched desktop experience

I remember the last line of CK patches (kernel 2.4).

The use experience delivered was unmatched! My modern x-Core machine does not as flawlessly play mp3s while several other tasks are running.

And that old thing was not even a new machine, when I bought it. But everybody who tried it was impressed, telling stories how their high-end hardware running other Linux kernels or Windows XP would start to stutter, when you would copy lots of data from A to B and stuff.

So the right test indeed would be to start all these tests that have been conducted simultaneously and play an mp3 or a video at the same time and then see, what happens.

[RealNC]

Take it easy. I didn't have problems understanding the phrase "millions hz" in the meaning of "a hole lot of hz". I don't think many would have problems doing so either.

That's not the problem. The problem is that it's not even 1Hz more. Not even 1! And yet he runs around with his "1 million Hz" BS. So no, it's not "a hole lot of hz." It's exactly the same as without BFS.

He just makes me wanna shoot bunnies every time he posts.

[misiu_mp]

Why the FUD? BFS recommends 1000Hz, not a million. Please show me where BFS recommends more than that. It's not even freakin' possible to use more than 1000Hz with BFS.

Ah, you mean the -ck patch, not BFS. You have no clue (again) what BFS is. And even the -ck patch in question even says that more than 1000Hz is only used for some broken software that depend on timer frequency and should not be used without a strong reason because it can break things.

You're a FUD spreader, kraftman. And the worst part is you know it, but simply don't give a shit.

Take it easy. I didn't have problems understanding the phrase "millions hz" in the meaning of "a hole lot of hz". I don't think many would have problems doing so either. Like that:

"The million is sometimes used in the English language as a metaphor for a very large number, as in "Never in a million years" and "You're one in a million", or a hyperbole, as in "I've walked a million miles" and "You've asked the million dollar question"."
-Wikipedia

[RealNC]

Why don't you use 3.0.1-rt11? It's much better than BFS...

I'm not running a professional studio or a nuclear reactor. Just normal audio applications that don't need RT facilities to the point of overkill. And rebooting to an RT kernel every time I want to work on audio is just a nuisance. I want my Linux desktop to have the same capabilities as Windows and Mac OS X out of the box. Furthermore, there's configuration involved when running apps in RT. In contrast, BFS just works.

So why should I be using the -rt kernel for audio apps? And it seems there's some agreement on this:

http://schivmeister.wordpress.com/2009/09/28/linux-audio-to-rt-or-to-bfs/

[darkbasic]

Maybe it's not Jack itself, but the whole audio chain, from the synths up to Jack. Lots of processes involved. With BFS, I can use 64 frames/period, no problem and no audio drops. Total latency of everything combined is well under 6ms. With CFS, it craps out as soon as I actually start playing some synths and CPU load rises. I have to raise latencies up to 15ms to make it work reliably.

It's really like day and night.

Why don't you use 3.0.1-rt11? It's much better than BFS...

[chronniff]

haha I just looked at Cons blog http://ck-hack.blogspot.com/ , and noticed that he had written an entry that basically says what I just did. Well I promise I'm not just regurgitating what he says, it just happens to be the truth

[chronniff]

if these benchmarks prove anything, it is that there isn't really any loss of throughput by using the BFS scheduler. This is actually a very good thing when considering that the scheduler aims at improving the responsiveness of desktops (not throughput), and often when one attempts to improve responsiveness it comes at the the cost of throughput. So logically, this article only proves that there is no downside to BFS, while leaving untested its upside. As someone who has been using BFS for most of its existence, while also usually testing out the mainline CFS with each new kernel release, there is no question that BFS is an improvement over CFS responsiveness. CFS has definately caught up a lot over the past year, but the difference between the two is still noticeable on a desktop.

[kraftman]

If BFS appears to fix kwin crashes, then that could indicate race conditions in kwin.

No, he was talking about something else, but it doesn't matter.

[kebabbert]

And please, Kraftman and RealNC, calm down. Your argument does not help anyone.

Back on topic: I heard that Con's patch helps responsiveness a lot. It seems some people agree on this. In that case, maybe the benchmark should include responiveness somehow? Are there any responsiveness benchmarks out there?