The v2 Rotary Interactivity Favor Scheduler

[3766691]

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.

[3766691]

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

[3766691]

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.

[ulenrich]

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

[3766691]

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

Thanks.
The new patch has solved the building issue

[3766691]

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.

[kernelOfTruth]

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 !

[3766691]

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

[3766691]

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.

[kernelOfTruth]

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 !