Announcement

Collapse
No announcement yet.

Two Years With Linux BFS, The Brain Fuck Scheduler

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #61
    Originally posted by RealNC View Post
    Yes, it is exactly as you describe. And that's because CFS is mandatory. If there wasn't BFS around, I would be *forced* to live with CFS. On the other hand, no one forces me to apply a silly patch that, even *if applied*, doesn't force anything but only introduces new choices that you have to enable yourself after reading a ton of warnings.

    Because of that, I can blame CFS but not an optional patch.
    And because of that I don't blame BFS, but the patch even if you thought otherwise.

    Comment


    • #62
      Originally posted by b15hop View Post
      That's exactly what I did. Cut drivers, cut wireless, cut certain encryption methods, cut ISA drivers or anything that was ancient. Anything I knew I didn't use. Only problem with doing this, I had to re compile if something didn't work. Which became a pain. That also meant that I learned what was what. Just cutting any random thing out is trial and error. So I would read up on what each section was used for. There are a LOT of different sub menu's...
      ...
      (edit) PS: Another thing I did was compile in kernel drivers. So the modules didn't load at start-up. That helped improve boot times. I think I had my NIC and (alsa) Audio drivers all compiled into the kernel. x) I notice that if I did a [ code] ps aux [/code ] I would get much less threads or processes with a minimised kernel. So the system felt less laggy and cleaner.
      Hmm, I though that unused drivers on a system are just that - unused. They shouldn't affect the speed of the system as the code would never execute. The startup time yes, but not run time.
      The lower amount of threads and processes is revealing though. This couldn't have been affected by just device drivers. You don't happen to be able to check exactly which threads and processes were gone and why?

      Comment


      • #63
        If you mean kernel threads, those like the XFS or JFS ones just idle until you actually mount a fs of that type. Having them there doesn't really cost anything.

        Comment


        • #64
          "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.

          Comment


          • #65
            Originally posted by yoshi314 View Post
            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.



            Sorry change all the millisecond junk in the post to microseconds.
            Last edited by Hephasteus; 12 September 2011, 10:17 PM.

            Comment


            • #66
              Originally posted by b15hop View Post
              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.

              Comment


              • #67
                Originally posted by damentz View Post
                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.

                Comment


                • #68
                  Originally posted by b15hop View Post
                  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.

                  Comment


                  • #69
                    Originally posted by damentz View Post
                    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.

                    Comment


                    • #70
                      Originally posted by RealNC View Post
                      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

                      Comment

                      Working...
                      X