Two Years With Linux BFS, The Brain Fuck Scheduler

[curaga]

Please do not respond to spambots..

[F.Ultra]

Well, don't openarena and unigine benches also list the min fps? That should be a good indicator.

FPS indicates throughput not latency. Latency is how fast the system reacts to change, which basically is the opposite of throughput. An extremely low latency desktop would have very low throughput which is why you see HPC servers using the lowest clock setting available with all realtime stuff turned off.

[RealNC]

I don't understand what the problem is. What's wrong with compiling and watching a video? I can do it, and so can Linus (after receiving the cgroup patch) and Phoronix even made a video about it (although phoronix does have ridiculously awesome hardware..)

cgroup never worked for me.

[renkin]

With 4.4.5 I also don't see problems with mainline.

Btw, "fast enough" for me means it shouldn't drop below 50FPS. If it does, it's not acceptable because it's distracting. Also, as a Gentoo user, I want the GUI to continue to be 100% fluid and be able to watch 1080p videos even if I'm compiling in the background with 100% CPU utilization. For me, only BFS delivers here.

I don't understand what the problem is. What's wrong with compiling and watching a video? I can do it, and so can Linus (after receiving the cgroup patch) and Phoronix even made a video about it (although phoronix does have ridiculously awesome hardware..)

..
x86_64 Intel(R) Core(TM)2 Duo CPU E7200 @ 2.53GHz GenuineIntel GNU/Linux

[b15hop]

No, less is more works well when you've exhausted all other solutions or your focus is security. When you're tweaking a system, you look for what's the root cause for your performance loss and fix that. Once done, you look at what's left and if there's still a problem.

You did the shotgun approach by removing things until there was nothing left to remove for your specific system. That's a really bad way of tweaking because you never find out what fixed the performance bug. All you can tell us is that by removing everything your hardware doesn't need, KDE performs faster.

Upload your configuration somewhere so we can take a look. I'm really curious what option you set that gave you such a large performance difference.

Problem is, the .config was never kept somewhere so I could recompile later... We're talking back when I used a single core 1.7ghz system when most people used 486 binaries. Cheers for asking though. I wish I kept it too. =(

Though in your own words, I don't see what's so bad about the shotgun approach. If it helped gain some speed it must have been worth it. What's to say that I do / do not know what I am supposed to remove in the first place. If I remember correctly the kernel has enough menu entries in make menuconfig to write a book.

[damentz]

All these theories are well and good. But how do I explain the speed increases from not including a heap of stuff. I do remember compiling some parts into the kernel rather than as modules. My understanding is that the smaller the kernel, the more of it fits into faster cpu cache... I could be wrong. Either way I had some speed increases. I do agree that disabling things doesn't make things easier. Also since then I have gone back to standard kernel as recompiling was just annoying after a while... Faster compile times doesn't really bother me. How about this for change then. Try running a time-demo in TWM vs KDE and see if there are speed increases. I strongly believe "less is more" when it comes to performance. Encumbering a computer in bloat usually kills performance. I'm not saying features are bad but when there are marginal losses, one does consider advantages of a minimalistic OS. All comes down to personal preference really.

No, less is more works well when you've exhausted all other solutions or your focus is security. When you're tweaking a system, you look for what's the root cause for your performance loss and fix that. Once done, you look at what's left and if there's still a problem.

You did the shotgun approach by removing things until there was nothing left to remove for your specific system. That's a really bad way of tweaking because you never find out what fixed the performance bug. All you can tell us is that by removing everything your hardware doesn't need, KDE performs faster.

Upload your configuration somewhere so we can take a look. I'm really curious what option you set that gave you such a large performance difference.

[b15hop]

b15hop, that's not how the kernel works. You might have used a different subsystem, but you can't remove a subsystem that's required at boot. Also, the different subsystems' disadvantages probably outweigh the advantages for modern desktop and laptop users.

I'm pretty sure all you did was disable swap and the tickless feature. Those are the only features that can really persistently affect responsiveness outside of the process scheduler (swap is not as optimal as you might think). As far as removing modules... you're just disabling the flexibility of your system for faster compile times. I'm pretty sure that's not a wisest idea.

All these theories are well and good. But how do I explain the speed increases from not including a heap of stuff. I do remember compiling some parts into the kernel rather than as modules. My understanding is that the smaller the kernel, the more of it fits into faster cpu cache... I could be wrong. Either way I had some speed increases. I do agree that disabling things doesn't make things easier. Also since then I have gone back to standard kernel as recompiling was just annoying after a while... Faster compile times doesn't really bother me. How about this for change then. Try running a time-demo in TWM vs KDE and see if there are speed increases. I strongly believe "less is more" when it comes to performance. Encumbering a computer in bloat usually kills performance. I'm not saying features are bad but when there are marginal losses, one does consider advantages of a minimalistic OS. All comes down to personal preference really.

[damentz]

I've tried using BFS. I don't see the huge advantage it brings. What helped me reduce latency was to compile my own kernel cut down to nothing. That helped a LOT. But who in their right mind is going to do that... How many Gentoo users here? I went to Arch linux for the fact that it was well built to start with. I even tried a BFS from compilation and it didn't really do much. I'm a big fan of reducing bloat to increase speed. I think that's far more important than curing the symptoms to work around the bloated problem. On a positive note, reducing bloat with added BFS might be a winning combo for meebo? Who knows? x)



I'd agree with you here but it's something I don't specialise in so I feel like my opinion has no weight. I think his scheduler works well, so all the critics can go jump. But I'm also one of those critics so I can go jump too. Mainly because as I said earlier, it didn't give me much improvement in speed. Compiling my own kernel that has been cut down to nothing helped a lot though.... These days I don't bother so I think the BFS should be given as an option. It's especially nice for distro's like gentoo, but I don't use gentoo. I like having options which is a valid reason to use Linux in the first place. PS no point getting emotional about it because it's not worth it. You probably know more than me here. I'm guessing the right combination of software and hardware make the BFS shine.



I had a similar problem with slackware ages ago. One of the reasons I tried recompiling the kernel was for that reason alone. I have to agree that CFS has terrible problems there... But tweaking the standard kernel fixed my problems.



Going by your information, this makes me believe that BFS is ideal for phones and other mobile devices. I am an AMD fanboy so not sure if that effects anything. (Phenom II 955 quad core)

PS: Back when I used BFS I was on a single core machine with only 1GB of ram... These days I use a quad core with 8GB of ram, which is why I don't bother recompiling it these days. Though in saying that, I really like the idea of BFS in a way because I think the current kernel is built around server technology and not desktops. Thus my theory that possibly BFS would be idea as an option for all us desktop users.



I get the feeling this is the only reason why M$ and Apple has such a huge upper hand over Linux. A happy (crazy) guy waving cash excites people.... Who can argue with that?

Kraftman: Why is anything bad? People will generally do what they want. At least we have an article to discuss something in the first place. We need more options like this to begin with.

b15hop, that's not how the kernel works. You might have used a different subsystem, but you can't remove a subsystem that's required at boot. Also, the different subsystems' disadvantages probably outweigh the advantages for modern desktop and laptop users.

I'm pretty sure all you did was disable swap and the tickless feature. Those are the only features that can really persistently affect responsiveness outside of the process scheduler (swap is not as optimal as you might think). As far as removing modules... you're just disabling the flexibility of your system for faster compile times. I'm pretty sure that's not a wisest idea.

[Hephasteus]

this benchmarks are totally inadequate. BFS scheduler is designed to reduce LATENCY in desktop applications.

i'd check for amount of frames dropped in some FPS game or quality of video capture framerate-wise, as this is where the scheduler latency matters. but these things cannot really be measured with a benchmark ( i think ).

before CFS epsxe emulator would stall randomly for ~0.5 second now and then. on CFS i sometimes get 0.1 sec delays, which is not the case with BFS at all. that is what should be measured, not performance of webserver or how much FPS can you squeeze of a game.

Phoronix staff - please, read again this post http://lkml.org/lkml/2009/9/6/231 and think about this article again.

dpclatency checker under windows says windows xp is a fast extremely responsive system. Under windows vista or 7 with the gpu scheduler it's a turd that can barely manage 80ms under a super hot system and you can get 7 and 9 ms under xp with decent hardware and 12ms with rediculously out of date. Unless of course you use wireless which it will go nuts from time to time or have a super bad hardware driver.

Until open source has a gpu scheduler then linux will turn into a giant unresponsive turd with 80 and 100 ms responsiveness ratings as well.

http://www.thesycon.de/deu/latency_check.shtml

Sorry change all the millisecond junk in the post to microseconds.

[RealNC]

"Cutting down" kernel drivers and features doesn't do anything else than faster kernel build times. Which is a good thing, of course. But people claiming that their system is now faster because they removed "bloat" from the kernel are usually just lying to themselves.