Originally posted by ulenrich
View Post
Announcement
Collapse
No announcement yet.
RIFS-ES Linux Kernel Scheduler Released
Collapse
X
-
Originally posted by ulenrich View PostChen,
could you give me a more detailed rationale, why
- I should use an older branch of code
- what is different in principle to RIFS-ES
- I could have more success in testing than you yourselfOriginally posted by TAXI View PostI know that disabling them fixes the errors, I just wanted to tell you so you can fix it in source.
But now I tried to compile it on a netbook with Intel Atom CPU:
block/built-in.o: In function `__blk_complete_request':
(.text+0x8345): undefined reference to `cpus_share_cache'
This time I don't know how to fix it.
//EDIT: Fixed by changing
shared = cpus_share_cache(cpu, ccpu);
to
shared = true; // Hardcoded for HT, else: cpus_share_cache(cpu, ccpu);
in block/blk-softirq.c
This code is for HyperThreading CPUs only and may fail on dual (or more) core CPUs. Also I couldn't test it yet as the netbook is slow and I have to do a lot more before I'm able to reboot.Originally posted by kernelOfTruth View PostI DO care about tickless :P
best compromise about interactivity, smoothness and energy savings
otherwise I could also use the rt-kernel
or aren't there that much energy savings with tickless enabled ?
This is RIFS-V3-Test(Actually is V5) based on RIFS-V2
It solved the interactivity problem RIFS-ES has.
EDIT 2
Wow, I have run the latt -c255 sleep 10 with music playing and browsing using firefox.
No lag with Music and Screen.
[admin@localhost ~]$ latt -c255 sleep 10
Parameters: min_wait=100ms, max_wait=500ms, clients=255
Entries logged: 765
Wakeup averages
-------------------------------------
Max 148215 usec
Avg 11210 usec
Stdev 20550 usec
Stdev mean 743 usec
Work averages
-------------------------------------
Max 1210226 usec
Avg 59141 usec
Stdev 89912 usec
Stdev mean 3251 usec
Remember to rename it to rifs.c and replace it with the original one.
Chen
Comment
-
Originally posted by 3766691 View PostHere I copy a whole things from the prev thread.
This is RIFS-V3-Test(Actually is V5) based on RIFS-V2
It solved the interactivity problem RIFS-ES has.
EDIT 2
Wow, I have run the latt -c255 sleep 10 with music playing and browsing using firefox.
No lag with Music and Screen.
[admin@localhost ~]$ latt -c255 sleep 10
Parameters: min_wait=100ms, max_wait=500ms, clients=255
Entries logged: 765
Wakeup averages
-------------------------------------
Max 148215 usec
Avg 11210 usec
Stdev 20550 usec
Stdev mean 743 usec
Work averages
-------------------------------------
Max 1210226 usec
Avg 59141 usec
Stdev 89912 usec
Stdev mean 3251 usec
Remember to rename it to rifs.c and replace it with the original one.
Chen
Although it will produce a bad latt benchmark result, it will produce good user experience.
@ulenrich @TAXI:
You can try whether it solves the building issue with some configuration or not.Last edited by 3766691; 25 June 2012, 06:36 AM.
Comment
-
BFS-O(1)-423. Patch the kernel with BFS first.
It is an improvement patch on data structure. As you see, the time complexity of BFS is O(n) and with this the time complexity become O(1).
Comment
-
@3766691:
smecenter has a point - overall RIFS-ES is a very smooth and great scheduler
to make it the best it is paramount that the max latencies also get smaller
I'm currently still using it with 3.4.2 and it's working great but from time to time there are small noticable lags during heavy i/o (the same with BFS & CFS)
it's not RIFS-ES/the cpu scheduler's fault if the i/o or VFS subsystem, device-mapper, etc. etc. screw up and lead to delays but it would at least be nice if the cpu scheduler could manage to keep latencies to a minimum on its own
any ideas on how to improve it more ?
otherwise it's awesome
thanks !
Comment
-
Originally posted by kernelOfTruth View Post@3766691:
smecenter has a point - overall RIFS-ES is a very smooth and great scheduler
to make it the best it is paramount that the max latencies also get smaller
I'm currently still using it with 3.4.2 and it's working great but from time to time there are small noticable lags during heavy i/o (the same with BFS & CFS)
it's not RIFS-ES/the cpu scheduler's fault if the i/o or VFS subsystem, device-mapper, etc. etc. screw up and lead to delays but it would at least be nice if the cpu scheduler could manage to keep latencies to a minimum on its own
any ideas on how to improve it more ?
otherwise it's awesome
thanks !
But still RIFS-v2 performs the best on your machine, isn't?
You may also see DMS SCHEDULER on the download page.
Comment
-
Originally posted by 3766691 View PostHeavy IO task always sleep with TASK_UNINTERRUPTIBLE. We can adjust the scheduler by this clue.
But still RIFS-v2 performs the best on your machine, isn't?
You may also see DMS SCHEDULER on the download page.
making it TASK_UNINTERRUPTIBLE would probably solve the issue with input lag during heavy i/o - especially under the amd64 architecture (intel only ?) - once and for all
provided of course that all the i/o (especially writing) is marked TASK_UNINTERRUPTIBLE
yeah, it's the best scheduler so far
what does that DMS Scheduler exactly change ? from what I read it prioritizes user input somehow and is swap aware ? is that correct ?
will test that one asap
great work !
thanks
Comment
-
Originally posted by kernelOfTruth View Postok, I see
making it TASK_UNINTERRUPTIBLE would probably solve the issue with input lag during heavy i/o - especially under the amd64 architecture (intel only ?) - once and for all
provided of course that all the i/o (especially writing) is marked TASK_UNINTERRUPTIBLE
yeah, it's the best scheduler so far
what does that DMS Scheduler exactly change ? from what I read it prioritizes user input somehow and is swap aware ? is that correct ?
will test that one asap
great work !
thanks
Comment
-
Originally posted by 3766691 View PostDMS is a cpu scheduler.The algo. it used is proportional fair(EDF) with O(1) time complexity
a fixed priority preemptive scheduling policy
I just tried it and the kernel hang during bringing up the CPUs so it must be an issue with the cpu scheduler
patched RIFS.ES-v1-low-spec-kernel3.4.x first and then replaced rifs.c with the one from "DMS-3.4.x V1(patch your kernel with RIFS-ES first)"
any ideas ?
thanks !
Comment
Comment