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

  • #31
    Originally posted by L33F3R View Post
    Woahhhh hold on Johnson. Someone tell me whats going on here.
    Google for "Android BFS Kernel". The BFS-enabled firmware is called "Cyanogen" I think (or maybe it's the nick of the dude who maintains it, dunno.)

    Note that BFS is actually not a ready or even released project. It's just a proof-of-concept at this point. It was able to boot on the machine it has been developed on only 15 days ago, with development starting from scratch about 20 days ago. So you do the math how "ready" it is :P

    Comment


    • #32
      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.
      That it did, but it's not the first time that the kernel devs and distro's seemed to have thought that desktop=workstation/server.

      Comment


      • #33
        Originally posted by deanjo View Post
        That it did, but it's not the first time that the kernel devs and distro's seemed to have thought that desktop=workstation/server.
        So I prefer workstation/server scheduler, because it doesn't choke like Windows one. When was this second time? When they replaced thing called SD which caused Tux racer to be unplayable and sound to stutter? If Con doesn't agree with Ingo's results he just should show some counter-results (if there's a way to measure some things...). This would be sane. There's always possibility BFS is better in some things (and it solved some people problems, so it's good because bfs brought more attention to some things).
        Last edited by kraftman; 10 September 2009, 11:03 AM.

        Comment


        • #34
          Originally posted by kraftman View Post
          So I prefer workstation/server scheduler, because it doesn't choke like Windows one.
          Actually, Windows turns out to be pretty good at this stuff now. Unless you mean Windows 95 :P

          Anyway, BFS was not created to replace mainline. It was created just to prove a point: When someone complained about lagging windows, compositing and such, the answer you got was "that's because X sucks, it's not made for multimedia desktops". I thought that too (also blamed fglrx, but it turns out, BFS fixed problems I blamed on fglrx, like mplayer dropping frames when I moved the window around or rotated KDE's desktop cube). Con wrote BFS and people realized "holy crap, it *is* the kernel's fault!"

          So in a sense, Kolivas won
          Last edited by RealNC; 10 September 2009, 02:33 PM.

          Comment


          • #35
            Originally posted by RealNC View Post
            So in a sense, Kolivas won
            But it seems BFS lost and CFS won (you know, don't you? ^^). Kolivas indirectly helped to catch some bug, but you helped directly :> This is great

            Some people can be disappointed, because it seems all those things they were talking about CFS are just myths and FUD

            However, I never had problems you described :>
            Last edited by kraftman; 10 September 2009, 03:00 PM.

            Comment


            • #36
              Originally posted by kraftman View Post
              But it seems BFS lost and CFS won (you know, don't you? ^^). Kolivas indirectly helped to catch some bug, but you helped directly :> This is great
              Well, I've just run the tests I was told to run by Ingo and others. If Con hadn't written BFS, most people would have simply assumed that the GUI lag is Compiz'/KDE's/X.Org's/Catalyst's fault instead of the kernel's.

              Some people can be disappointed, because it seems all those things they were talking about CFS are just myths and FUD
              Nevertheless they should be happy if it gets fixed for good.

              However, I never had problems you described :>
              Do you have composite enabled? (Compiz/KDE4 etc). The problem mostly manifests with composite effects since the compositor is competing for interactivity with the applications it is actually compositing. If I turn off desktop effects, I also don't have any issues :P

              Comment


              • #37
                Originally posted by RealNC View Post
                Do you have composite enabled? (Compiz/KDE4 etc). The problem mostly manifests with composite effects since the compositor is competing for interactivity with the applications it is actually compositing. If I turn off desktop effects, I also don't have any issues :P
                Yes, I have KDE 4 composition enabled and I can switch smplayer with Amarok etc. using alt+tab and it works excellent Music is playing same time and I can even run OpenSSL test However, I'm using open source radeon driver and maybe this helps in some part.

                EDIT:

                Ooops, sorry. I can benchmark OpenSSL, but I must have composition disabled, because movie isn't smooth then.
                Last edited by kraftman; 10 September 2009, 03:47 PM.

                Comment


                • #38
                  OK, last test:

                  Make sure you're using the Oxygen widget style in KDE4 (for the rounded menus). Open a video in SMPlayer and have "gl2(yuv)" selected as renderer. Then, while the video is playing in windowed mode, simply open one of the SMPlayer menus so that it will drop-down and cover part of the video. When that happens, does the video appear to play "jerky" and slow? For some reason, with CFS using NEW_FAIR_SLEEPERS, the video just lags here. With BFS and CFS using NO_NEW_FAIR_SLEEPERS, everything is fine. This must have something to do with Oxygen's rounded menus (alpha blending is probably involved here?)

                  And, are you on an AMD or Core I5/I7 CPU?

                  PS:
                  I also ran tests with the open source drivers.
                  Last edited by RealNC; 10 September 2009, 03:56 PM.

                  Comment


                  • #39
                    Originally posted by RealNC View Post
                    Make sure you're using the Oxygen widget style in KDE4 (for the rounded menus). Open a video in SMPlayer and have "gl2(yuv)" selected as renderer. Then, while the video is playing in windowed mode, simply open one of the SMPlayer menus so that it will drop-down and cover part of the video. When that happens, does the video appear to play "jerky" and slow? For some reason, with CFS using NEW_FAIR_SLEEPERS, the video just lags here. With BFS and CFS using NO_NEW_FAIR_SLEEPERS, everything is fine. This must have something to do with Oxygen's rounded menus (alpha blending is probably involved here?).
                    Hey I'm experiencing exactly that. Interesting to see the scheduler is at fault.
                    Is there a easy way to disably this NEW_FAIR_SLEEPERS you're talking about? Kernel-rebuild would be ok, but I'm stuck at 2.6.28 (fglrx 9-3) so an update wouldn't be possible.

                    Comment


                    • #40
                      It's not configurable by means of "make menuconfig" and such, but it's still easy. From inside the kernel source tree, open "kernel/sched_features.h" in an editor and the first line there should be:

                      SCHED_FEAT(NEW_FAIR_SLEEPERS, 1)

                      Replace the 1 with a 0 there. Then simply rebuild the kernel and boot it.

                      Comment

                      Working...
                      X