Announcement

Collapse
No announcement yet.

Con Kolivas is working on a new scheduler for Desktop/Multimedia/Gaming PCs

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

  • #46
    Originally posted by BlackStar View Post
    Ingo may not have meant it like this, but using such hardware really felt like a deliberate attempt to disprove Con's scheduler.
    I'm pretty sure Ingo didn't mean it like that- but unfortunately, everyone over there in LKML appear to have fallen for the "lowest RMS error" folly. If you're doing server stuff, yeah, in the large, you want what Ingo's talking to. However, once you introduce a UI, text or graphic, the rules should change a bit.

    I'm on the fence about this issue, since I haven't really felt any issues with the current scheduler, but if the improvements on single-, dual-, tri- and quad-core systems are repeatable (you know, the hardware desktop PCs actually *have*), then we might have something good on our hands.
    There IS an issue with what we've got as the default. It's not as interactive as the old way of doing things. But, in the same vein, I'm concuring with Con on BFS- it's a demo to show there IS an issue and there can be considerable room for improvement. Ingo and the others are going "but the latency..." not realizing that some latencies are actually needed because humans don't work in lock-step with how the computer works. We have a sliding window atom of attention of about 100msec. If you catch things just right, they seem fluid and are "snappy". Miss the window in the wrong way (and there's several of them...try talking with a delay-line of 150msec applied to what you hear of your speech...) and things feel "laggy" at the least, if not worse. With the introduction of CFS and a few other things, while the overall base performance is impressive, the interactivity suffers while under load.

    The issue is that kernel devs are (rightly) extremely resistant to change on this area. However, if this shows so significant improvements that Android and other distros adapt it (despite being an out of tree patch), we will likely see one of two things:
    1. This makes it into the kernel. (Patch from Con? Yeah, right...)
    2. CFS is improved to match BFS on the desktop.
    I think Con's actually trying to get #2 to happen. That's his stated goals with BFS. He's making it so it largely works, but would be nothing that the kernel crowd would accept into the tree unless there was something like pluggable scheduler modules. And it does seem to show real improvements in interactivity (Even Ingo observed this much...)- only a slight degredation in some areas (Which is where much of the issue at the moment lies- everyone's worrying about lowest latency, which is good, but how they're getting it sacrifices interactivity). For a desktop or handheld device, I suspect once he works the bulk of the kinks out there'll be some more serious looking at what he's trying to tell everyone (yet again...). I'm hoping Ingo takes the hint here and looks into what he missed on CFS and comes up with improvements or an "acceptable" answer to what Con's showing us right now.

    Comment


    • #47
      Originally posted by suokko View Post
      Gnome does use trapezoids a lot which makes gtk very slow. Too bad trapezoids are hard to gpu accelerate so if you are good at drawing smooth lines patches are welcome to add GPU accerlation to open drivers.
      Heh... Depends on if you're using OpenGL as the base rendering layer for acceleration or not. Trapezoids are fairly easy to accelerate under it- and if you munge the algorithm they use for breaking apart GL_QUADS into triangles, you can do nearly the same thing with 2D accel.

      Comment


      • #48
        @Sfartalf

        Everything should be fine:

        http://lkml.org/lkml/2009/9/10/229

        Comment


        • #49
          Originally posted by Svartalf View Post
          Heh... Depends on if you're using OpenGL as the base rendering layer for acceleration or not. Trapezoids are fairly easy to accelerate under it- and if you munge the algorithm they use for breaking apart GL_QUADS into triangles, you can do nearly the same thing with 2D accel.
          Except that GPU rendering doesn't exactly match the X requirements so you would have to do it with shaders.

          Comment


          • #50
            BFS benchmarks coming next week off 2.6.31 final.
            Michael Larabel
            http://www.michaellarabel.com/

            Comment


            • #51
              @Svartalf: Trippppple Kill

              @Michael: Thanks. I eagerly anticipate this 1

              Comment


              • #52
                Originally posted by Michael View Post
                BFS benchmarks coming next week off 2.6.31 final.
                Please don't forget to also check with mainline but with NEW_FAIR_SLEEPERS disabled. I assume that kernel debug features will be disabled for benchmarks, so to disable that option you can simply change the default from 1 to 0 in kernel/sched_features.h.

                PS:
                I suppose everyone knows that BFS will not win any benchmarks, right? The Phoronix Test Suite can not benchmark any of the issues BFS tries to solve.

                Comment


                • #53
                  Originally posted by RealNC View Post
                  Please don't forget to also check with mainline but with NEW_FAIR_SLEEPERS disabled. I assume that kernel debug features will be disabled for benchmarks, so to disable that option you can simply change the default from 1 to 0 in kernel/sched_features.h.

                  PS:
                  I suppose everyone knows that BFS will not win any benchmarks, right? The Phoronix Test Suite can not benchmark any of the issues BFS tries to solve.
                  I've seen rumors of BFS significantly decreasing compile times. Something like "BFS turned a 12 hour compile into 10 hours!!!" - I forget where I saw it.

                  He could also do FPS and gtkperf benches with a background process burning cpu, or something like that.

                  Comment


                  • #54
                    Originally posted by StringCheesian View Post
                    I've seen rumors of BFS significantly decreasing compile times. Something like "BFS turned a 12 hour compile into 10 hours!!!" - I forget where I saw it.
                    This is due to a regression in mainline where CPUs are under-utilized. For example a "make -j2" in dual-core machine only uses about 90% CPU. BFS uses 100% so yes, it finishes faster. Not sure if everyone is affected here.

                    He could also do FPS and gtkperf benches with a background process burning cpu, or something like that.
                    That one is actually pretty much the whole point of BFS.

                    Comment


                    • #55
                      Originally posted by RealNC View Post
                      PS:
                      I suppose everyone knows that BFS will not win any benchmarks, right? The Phoronix Test Suite can not benchmark any of the issues BFS tries to solve.
                      Actually it can. BFS is "faster" here in pgbech, but I tested CFS in KDE terminal (and NEW_FAIR_SLEEPERS were enabled) and BFS only in vt (DE was not running), because I have some issues with it in graphical environment. There are also problems with BFS like some processes get caught in infinite loops.

                      CFS with NEW_FAIR_SLEEPERS disabled should perform better in my opinion. Those problems with compilation times were also addressed.

                      That one is actually pretty much the whole point of BFS
                      The same about CFS. Just some issues had to be fixed

                      Comment


                      • #56
                        Originally posted by kraftman View Post
                        The same about CFS. Just some issues had to be fixed
                        That's why it's always good to have alternatives and people "challenging" the system. Chances are if BFS didn't come around regressions (if it is even a regression or it was just broken from the start) probably wouldn't have been addressed in CFS for quite some time.

                        Comment


                        • #57
                          Originally posted by deanjo View Post
                          That's why it's always good to have alternatives and people "challenging" the system. Chances are if BFS didn't come around regressions (if it is even a regression or it was just broken from the start) probably wouldn't have been addressed in CFS for quite some time.
                          Yes, I completely agree. This is great.

                          Reading some forums it seems mainly Intel CPUs have those problems. Like RealNC said.
                          Last edited by kraftman; 09-13-2009, 11:06 AM.

                          Comment


                          • #58
                            Someone should measure graphic performance, because it's something very important on desktops (yeah, I know, but I believe there will be some games on Linux someday ). In Urban Terror I have double more FPS using CFS scheduler then with BFS (Amarok must be running same time!!! if I run only UT it seems FPS amount is the same). BFS also kills my input sometimes.

                            When comes to compilation time BFS does better, but with *Sleepers* disabled in CFS it should be at least as good as BFS. Whatever Phoronix results will be, it seems it won't be fair comparison. BFS "ignores" just too many things which drives to dead input, processes and thus it can be "faster" in some benchmarks. It will be great to see fixed CFS vs more mature BFS results someday.

                            P.S. I used generic Arch Linux kernel vs BFS patched kernel from AUR.

                            Btw. with NO_NEW_FAIR_SLEEPERS pgbench result is much lower (BFS : CFS : CFS_NNFS using debugfs) - 1650 : 1350 : 935 +/-.
                            Last edited by kraftman; 09-13-2009, 01:32 PM.

                            Comment

                            Working...
                            X