Announcement

Collapse
No announcement yet.

The v2 Rotary Interactivity Favor Scheduler

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

  • #61
    I decided to test RIFS v2, v3-RC1, v3-RC2, and CFS 3.4-rt.
    All three of RIFS get high latency on a standard cyclictest run (50us instead of the average 1 on CFS or 0 on BFS or CFS+RT-preempt).
    Using 'latt stress -c 64', v3-RC2 hangs the machine completely (just like BFS), v3-RC1 nearly does so and if you're lucky you can kill it.
    Wakeup latencies (according to latt) on RC2 are in the 500us range average.

    v2 works as advertised, and up to 128 threads will keep CPU bound tasks going fine, and latt reports wakeup latencies in the 3us range for 32 threads, but 1028 us for 64. Notably, I/O seems to get starved, however. They are entirely inconsistent, however.

    As far as miscellaneous problems... On v2, results with latt are inconsistent in returning. Sometimes it'll return nothing at all. v3-RC2 occasionally won't boot because the storage subsystem hasn't initialized by the time it tries to boot (haven't seen that before, and only sometimes on v3-RC2).
    However, kernel compile times on v2 (make -j4) seem to take much, much longer than with anything else. On the order of 3 times longer.

    All of this is in X11 and with r600g, with a Touhou 3D game (via wine) running concurrently with the tests to ensure things are really interactive and that audio works correctly.

    3.4-rt (CFS) seems to work correctly anywhere from -c1 to -c256, with latt-reported wakeups in the 3 average, 10 max for 64 stress processes. 66 average, 818 max for 256 stress processes. CFS-rt doesn't starve I/O.

    Comment


    • #62
      Originally posted by Zephiris View Post
      I decided to test RIFS v2, v3-RC1, v3-RC2, and CFS 3.4-rt.
      All three of RIFS get high latency on a standard cyclictest run (50us instead of the average 1 on CFS or 0 on BFS or CFS+RT-preempt).
      Using 'latt stress -c 64', v3-RC2 hangs the machine completely (just like BFS), v3-RC1 nearly does so and if you're lucky you can kill it.
      Wakeup latencies (according to latt) on RC2 are in the 500us range average.

      v2 works as advertised, and up to 128 threads will keep CPU bound tasks going fine, and latt reports wakeup latencies in the 3us range for 32 threads, but 1028 us for 64. Notably, I/O seems to get starved, however. They are entirely inconsistent, however.

      As far as miscellaneous problems... On v2, results with latt are inconsistent in returning. Sometimes it'll return nothing at all. v3-RC2 occasionally won't boot because the storage subsystem hasn't initialized by the time it tries to boot (haven't seen that before, and only sometimes on v3-RC2).
      However, kernel compile times on v2 (make -j4) seem to take much, much longer than with anything else. On the order of 3 times longer.

      All of this is in X11 and with r600g, with a Touhou 3D game (via wine) running concurrently with the tests to ensure things are really interactive and that audio works correctly.

      3.4-rt (CFS) seems to work correctly anywhere from -c1 to -c256, with latt-reported wakeups in the 3 average, 10 max for 64 stress processes. 66 average, 818 max for 256 stress processes. CFS-rt doesn't starve I/O.
      .
      It is quite interesting. Could you send me your .config to my email? Thank you for your work
      Maybe it is better to change do-while to jump instructions.Optimising is needed otherwise miscaching will happen frequently
      Last edited by 3766691; 22 May 2012, 06:20 AM.

      Comment


      • #63
        Originally posted by elmariachi View Post
        Could you make the patch version agnostic? It works with 3.3.6 without a hitch (so far), and having to manually find&replace the version everytime is time-consuming. So far all is fine for my day-to-day usage.
        Anyway, rifs v3 will use the algorithm v2 used, there will be a little change. Also, it may be worth to try to hook the mouse or keyboard driver to identify whether it is a user-interactive task. If it is, the priority of it will become RR(It seems ugly but be worth to try.)

        Comment


        • #64
          hehe giving RR to mouse and keyboard isn't a very good thing
          how do you find if they user-interactive?

          Comment


          • #65
            Originally posted by elmariachi View Post
            hehe giving RR to mouse and keyboard isn't a very good thing
            how do you find if they user-interactive?
            Hook the driver by a little patch
            Also now RIFS doesnt do that(it seems a bit ugly)

            Comment


            • #66
              I don't want to sound too critical Chen, but your google code page is starting to become a mess :/ if you want people to contribute/follow your project more closely why not use a git repo (like github)? Or at least come up with a better naming scheme for your versions, I already lost track of what's working and what isn't :s

              Comment


              • #67
                Originally posted by elmariachi View Post
                I don't want to sound too critical Chen, but your google code page is starting to become a mess :/ if you want people to contribute/follow your project more closely why not use a git repo (like github)? Or at least come up with a better naming scheme for your versions, I already lost track of what's working and what isn't :s
                When i have time i will move them to a svn server.

                Comment


                • #68
                  Originally posted by Zephiris View Post
                  I decided to test RIFS v2, v3-RC1, v3-RC2, and CFS 3.4-rt.
                  All three of RIFS get high latency on a standard cyclictest run (50us instead of the average 1 on CFS or 0 on BFS or CFS+RT-preempt).
                  Using 'latt stress -c 64', v3-RC2 hangs the machine completely (just like BFS), v3-RC1 nearly does so and if you're lucky you can kill it.
                  Wakeup latencies (according to latt) on RC2 are in the 500us range average.

                  v2 works as advertised, and up to 128 threads will keep CPU bound tasks going fine, and latt reports wakeup latencies in the 3us range for 32 threads, but 1028 us for 64. Notably, I/O seems to get starved, however. They are entirely inconsistent, however.

                  As far as miscellaneous problems... On v2, results with latt are inconsistent in returning. Sometimes it'll return nothing at all. v3-RC2 occasionally won't boot because the storage subsystem hasn't initialized by the time it tries to boot (haven't seen that before, and only sometimes on v3-RC2).
                  However, kernel compile times on v2 (make -j4) seem to take much, much longer than with anything else. On the order of 3 times longer.

                  All of this is in X11 and with r600g, with a Touhou 3D game (via wine) running concurrently with the tests to ensure things are really interactive and that audio works correctly.

                  3.4-rt (CFS) seems to work correctly anywhere from -c1 to -c256, with latt-reported wakeups in the 3 average, 10 max for 64 stress processes. 66 average, 818 max for 256 stress processes. CFS-rt doesn't starve I/O.
                  The problem is cause by a bug in these 3 scheduler. I have fixed it but i havent post it yet.

                  Comment


                  • #69
                    Originally posted by elmariachi View Post
                    I don't want to sound too critical Chen, but your google code page is starting to become a mess :/ if you want people to contribute/follow your project more closely why not use a git repo (like github)? Or at least come up with a better naming scheme for your versions, I already lost track of what's working and what isn't :s
                    Sorry for it. I will tidy it.

                    Comment


                    • #70
                      Originally posted by 3766691 View Post
                      When i have time i will move them to a svn server.
                      Please move to git instead, noone wants to use svn anymore.
                      ## VGA ##
                      AMD: X1950XTX, HD3870, HD5870
                      Intel: GMA45, HD3000 (Core i5 2500K)

                      Comment

                      Working...
                      X