Page 12 of 15 FirstFirst ... 21011121314 ... LastLast
Results 111 to 120 of 146

Thread: The v2 Rotary Interactivity Favor Scheduler

  1. #111
    Join Date
    May 2012
    Location
    GuangDong,China
    Posts
    141

    Default

    Quote 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.

  2. #112
    Join Date
    May 2012
    Location
    GuangDong,China
    Posts
    141

    Default

    Quote 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; 06-18-2012 at 06:04 PM.

  3. #113
    Join Date
    May 2012
    Location
    GuangDong,China
    Posts
    141

    Default

    Quote 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.

  4. #114
    Join Date
    Oct 2011
    Posts
    56

    Default

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

  5. #115
    Join Date
    May 2012
    Location
    GuangDong,China
    Posts
    141

    Default

    Quote 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

  6. #116
    Join Date
    May 2012
    Location
    GuangDong,China
    Posts
    141

    Default

    Quote 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.

  7. #117
    Join Date
    Jan 2009
    Location
    Vienna, Austria; Germany; hello world :)
    Posts
    622

    Default

    Quote 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:

    http://phoronix.com/forums/showthrea...duler-Released



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

    thanks !
    Last edited by kernelOfTruth; 06-19-2012 at 01:08 PM.

  8. #118
    Join Date
    May 2012
    Location
    GuangDong,China
    Posts
    141

    Default

    Quote 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:

    http://phoronix.com/forums/showthrea...duler-Released



    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);
    }

  9. #119
    Join Date
    May 2012
    Location
    GuangDong,China
    Posts
    141

    Default

    Quote 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:

    http://phoronix.com/forums/showthrea...duler-Released



    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.

  10. #120
    Join Date
    Jan 2009
    Location
    Vienna, Austria; Germany; hello world :)
    Posts
    622

    Default

    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 !

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •