Announcement

Collapse
No announcement yet.

The v2 Rotary Interactivity Favor Scheduler

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

  • Originally posted by ulenrich View Post
    CC kernel/power/suspend.o
    * CC kernel/power/poweroff.o
    * LD kernel/power/built-in.o
    * CC kernel/sched/rifs.o
    * CC arch/x86/kernel/cpu/mcheck/mce.o
    *kernel/sched/rifs.c:343:19: fatal error: stats.h: No such file or directory
    *compilation terminated.

    By the way, this gets an empty git:
    git clone https://code.google.com/p/rifs-scheduler
    Sorry I will check it after several hours.
    You can create an empty file and rename it to "stats.h' in /kernel/sched to solve this.

    Comment


    • Originally posted by kernelOfTruth View Post
      thanks !

      yeah, what I experienced so far

      RIFS vs. RIFS-ES isn't much difference noticable under "normal" productivity load

      but under pretty heavy load it probably is noticable


      BFS was already quite good but had some issues since I upgraded my hardware from Core 2 Duo to Core i7 Quad (+ HT) at least it wasn't the same


      CFS improves with newer kernel releases and it quite nice with autogroup but obviously needs improvements (little sound/video stuttering from time to time during heavy i/o, etc.)


      RIFS / RIFS-ES is best so far - very very good for desktop usage


      Chen, could you also make a port for 2.6.35, 2.6.39 and 3.0/3.1 kernels ?


      I believe the XDA devs might love it (I'm an XDA dev myself) and it would definitely improve smoothness and responsiveness with less overhead on the phones

      besides that RIFS would get more testing, fame and geek status


      thanks for considering
      Hi KOT
      Could you tell me under heavy load which one(RIFS and RIFS-ES) is better?Thanks.(It is quite difficult to show which one is better with benchmark)
      I will make a port for the old kernel by rewriting it in modular form (since 2.6.35 are is used in Android)

      Thanks for comments and feedbacks!

      Chen
      Last edited by 3766691; 18 June 2012, 06:04 PM.

      Comment


      • Originally posted by 3766691 View Post
        Sorry I will check it after several hours.
        You can create an empty file and rename it to "stats.h' in /kernel/sched to solve this.
        I am also using gcc 4.6.

        Comment


        • Yes, your RIFS-V1 newest edition without stat.h
          - compiles
          - and runs
          cleanly!

          Comment


          • Originally posted by ulenrich View Post
            Yes, your RIFS-V1 newest edition without stat.h
            - compiles
            - and runs
            cleanly!
            Thanks.
            The new patch has solved the building issue

            Comment


            • Originally posted by kernelOfTruth View Post
              thanks !

              yeah, what I experienced so far

              RIFS vs. RIFS-ES isn't much difference noticable under "normal" productivity load

              but under pretty heavy load it probably is noticable


              BFS was already quite good but had some issues since I upgraded my hardware from Core 2 Duo to Core i7 Quad (+ HT) at least it wasn't the same


              CFS improves with newer kernel releases and it quite nice with autogroup but obviously needs improvements (little sound/video stuttering from time to time during heavy i/o, etc.)


              RIFS / RIFS-ES is best so far - very very good for desktop usage


              Chen, could you also make a port for 2.6.35, 2.6.39 and 3.0/3.1 kernels ?


              I believe the XDA devs might love it (I'm an XDA dev myself) and it would definitely improve smoothness and responsiveness with less overhead on the phones

              besides that RIFS would get more testing, fame and geek status


              thanks for considering
              Also i have posted the newest latency-related benchmark.

              Comment


              • Originally posted by 3766691 View Post
                Also i have posted the newest latency-related benchmark.
                man, that's impressive to say the least


                BFS & CFS linearly "scale" for worse latency and RIFS-ES (already better) after 60-70 clients gets better and better with more and more clients

                fascinating !


                no idea about scheduling but there's surely some way to improve it even more (interestingly it scales similarly like BFS up to 50 and then between 55 - around 72 it's worse but then gets significantly better - might this be an issue
                with parts from mainline ? - you're partly using stuff from mainline - right ?)

                [I'm referring to Result-001.PNG, "Benchmark between RIFS-ES, CFS, BFS(latt, 64-200 clients)"]



                oh - kudos where kudos are due:





                I'll get around in about a week to test it again under very heavy load

                thanks !
                Last edited by kernelOfTruth; 19 June 2012, 01:08 PM.

                Comment


                • Originally posted by kernelOfTruth View Post
                  man, that's impressive to say the least


                  BFS & CFS linearly "scale" for worse latency and RIFS-ES (already better) after 60-70 clients gets better and better with more and more clients

                  fascinating !


                  no idea about scheduling but there's surely some way to improve it even more (interestingly it scales similarly like BFS up to 50 and then between 55 - around 72 it's worse but then gets significantly better - might this be an issue
                  with parts from mainline ? - you're partly using stuff from mainline - right ?)

                  [I'm referring to Result-001.PNG, "Benchmark between RIFS-ES, CFS, BFS(latt, 64-200 clients)"]



                  oh - kudos where kudos are due:





                  I'll get around in about a week to test it again under very heavy load

                  thanks !
                  This is the effect of ES feature. If a task has not run for long time, it can get the high prio more faster.
                  If a task sleep and wake up very often it can still gain high priority but the priority will be lower than some task like:
                  int main()
                  {
                  int i;
                  for(i = 0;i < 60;i++)
                  sleep(1);
                  }

                  Comment


                  • Originally posted by kernelOfTruth View Post
                    man, that's impressive to say the least


                    BFS & CFS linearly "scale" for worse latency and RIFS-ES (already better) after 60-70 clients gets better and better with more and more clients

                    fascinating !


                    no idea about scheduling but there's surely some way to improve it even more (interestingly it scales similarly like BFS up to 50 and then between 55 - around 72 it's worse but then gets significantly better - might this be an issue
                    with parts from mainline ? - you're partly using stuff from mainline - right ?)

                    [I'm referring to Result-001.PNG, "Benchmark between RIFS-ES, CFS, BFS(latt, 64-200 clients)"]



                    oh - kudos where kudos are due:





                    I'll get around in about a week to test it again under very heavy load

                    thanks !
                    For each benchmark, I will make sure that the system is truely idle first.
                    Then, run latt -cN sleep 10 > sched_name.resultN
                    after one measurement is finished I will idle my system(Not moving the mouse) for 20s and run the second benchmark.

                    If i didn't idle my system and run the benchmark, the latency result for latt -c200 will still be lower than both BFS and CFS but the latency is much higher because it will be treated as a io-bound task.

                    Comment


                    • did some data backup and at the same time used the opportunity to watch 1080p video + 2 sound streams (including the hd video's stream)

                      at least 5-10 times it stopped for 1-2 seconds


                      observations so far:

                      1) there seem to be issues with the sound system (probably pulseaudio related)

                      would renice hep ?

                      2) with heavy writing + HD video it lags pretty much - so there's issues with i/o, I'm already using BFQ but seemingly there's still room for improvements

                      3) amd64: there seems to be more issues with heavy i/o (see the amd64 gentoo subforum on forums.gentoo.org)


                      so I'll see during the next days on regular / everyday usage how it goes


                      will at earliest be able to compare in a week with the non-ES



                      impression so far: it only might be a feeling but the non-ES RIFS felt a little more fluid, dunno (especially when comparing the total halt of sound + video of HD video streaming - weird, gotta check next time if the video-streaming stopped or if it really was due to heavy i/o)


                      thanks !

                      Comment

                      Working...
                      X