RIFS-ES Linux Kernel Scheduler Released

[3766691]

I am publishing my esperience here:
http://siduction.org/index.php?name=...93b39deb#21450

Siduction is an effective an little community around Debian unstable. Towo, the kernel guy there, had applied BFS patches for Linux-3.2 back then. But you dont have to use it to discuss in the forums. My main distribution yet is Gentoo, which is not only a "rollin' release" but a rolling MYrelease.

The original version of RIFS-ES is broken with design already. Seems many people like RIFS-ES-Low-Spec so in 3.5 kernel it will be the offical one. RIFS V2 will still be updated to make a compairsion between RIFS and RIFS-ES

Sometimes we want to avoid somethings by some little tricky design, but almostly the one which has no tricky design is the best.
In LKML I have mention that the tricky design has destroyed CFS. One more things I have to mention is, the time complexity of RIFS and RIFS-ES-LOW-SPEC is O(1)

[ulenrich]

Chen
it is the time some one comes up (again), to try to convince mainline of a
compile time plugin source structure regarding schedulers!

All needed to alter the scheduler should be only at
linux/kernel/sched/cfs/
linux/kernel/sched/rifs/
linux/kernel/sched/bfs/
linux/kernel/sched/my/
one place,
no more patching necessary of all these
+++ linux-3.4.1-RIFS/fs/proc/base.c
+++ linux-3.4.1-RIFS/include/linux/init_task.h
+++ linux-3.4.1-RIFS/kernel/delayacct.c
+++ linux-3.4.1-RIFS/kernel/exit.c
+++ linux-3.4.1-RIFS/kernel/posix-cpu-timers.c
+++ linux-3.4.1-RIFS/kernel/sysctl.c

[3766691]

Chen
it is the time some one comes up (again), to try to convince mainline of a
compile time plugin source structure regarding schedulers!

All needed to alter the scheduler should be only at
linux/kernel/sched/cfs/
linux/kernel/sched/rifs/
linux/kernel/sched/bfs/
linux/kernel/sched/my/
one place,
no more patching necessary of all these
+++ linux-3.4.1-RIFS/fs/proc/base.c
+++ linux-3.4.1-RIFS/include/linux/init_task.h
+++ linux-3.4.1-RIFS/kernel/delayacct.c
+++ linux-3.4.1-RIFS/kernel/exit.c
+++ linux-3.4.1-RIFS/kernel/posix-cpu-timers.c
+++ linux-3.4.1-RIFS/kernel/sysctl.c

The patching for these 5 place is because CFS haa been hard-coded to the hole kernel. So we need to modify them.
init_task.h is used for filling the task_struct of init process, so modify it is needed.
It seems like that the kernel maintainer doesn't want us to develop our own scheduler.

[3766691]

The patching for these 5 place is because CFS haa been hard-coded to the hole kernel. So we need to modify them.
init_task.h is used for filling the task_struct of init process, so modify it is needed.
It seems like that the kernel maintainer doesn't want us to develop our own scheduler.

Let me mention more. The vanilla scheduler is now totally not for desktop and even the interactivity of Windows is better than vanilla(Though both of them sucks). Ralph, you can read the LKML message between me and Ingo:

On Wed, 2012-05-23 at 17:50 +0200, Ingo Molnar wrote:

> * Joe Perches <joe@perches.com> wrote:
> > In a 1000 cpu config, there also an extra 500+ bytes per cpu
> > in printk (I don't think that's particularly important btw)
> A 1000 cpu piece of hardware will have a terabyte of RAM or
> more. 0.5K per CPU is reasonable.


That's not fundamentally true, but it's not
particularly important right now either.

cheers, Joe
===================

* Chen <hi3766691@gmail.com> wrote:

> Oh, Just count the size of the scheduler code yourself,
> actually 400 - 500k. core.c + fair.c + rt.c + idle_task.c +
> everything

Only binary code is counted in bytes, source code is counted in
lines.

20 KLOC for a full-featured CPU scheduler that does everything
from simple UP scheduling to thousands of CPUs NUMA scheduling,
cgroups, real-time and more, is entirely reasonable.

As a comparison the VM is 80+ KLOCS, arch/x86/ is 260+ KLOCs,
networking is 720+ KLOCS and the FS subsystem is over 1 million
lines of code.

The scheduler is in fact one of the smaller subsystems.

Thanks,

Ingo
================

* Chen <hi3766691@gmail.com> wrote:

> Oh, Just count the size of the scheduler code yourself,
> actually 400 - 500k. core.c + fair.c + rt.c + idle_task.c +
> everything

Only binary code is counted in bytes, source code is counted in
lines.

20 KLOC for a full-featured CPU scheduler that does everything
from simple UP scheduling to thousands of CPUs NUMA scheduling,
cgroups, real-time and more, is entirely reasonable.

As a comparison the VM is 80+ KLOCS, arch/x86/ is 260+ KLOCs,
networking is 720+ KLOCS and the FS subsystem is over 1 million
lines of code.

The scheduler is in fact one of the smaller subsystems.

Thanks,

Ingo


He tries to compare the line of code between sched-subsystem, filesystem and even VM and said his code is not bloated and it is even a small subsystem.
BrainF*ck!!!

[ulenrich]

Chen,
that queer discussion just shows the importance of my point:
Seperate the scheduler code!

This seperation could serve a fresh start to improve the technique of the beating heart the scheduler!

[3766691]

Chen,
that queer discussion just shows the importance of my point:
Seperate the scheduler code!

This seperation could serve a fresh start to improve the technique of the beating heart the scheduler!

It must be done someday and even now.
I am now trying to let RIFS-ES get into Gentoo source. Also I have finished the porting of 3.5.x kernel.

[TAXI]

Also I have finished the porting of 3.5.x kernel.

Would you please share the patch? Would love to test it.

[kernelOfTruth]

Would you please share the patch? Would love to test it.

++

I second that


will try it next week - by then additional fixes for btrfs probably will get in and the kernel should be pretty usable/stable

[3766691]

++

I second that


will try it next week - by then additional fixes for btrfs probably will get in and the kernel should be pretty usable/stable

Wait I am playing LOL right now.

[ulenrich]

Chen,
could you look into the sleepy thingy once more?
I recently had a little annoyance with my wlan, this happened two times :
- doing something not internet related (watching soccer dvb-t using kaffeine) longer than an hour
- lost my wlan internet connection
The same happened directly after this a second time the same conditions.

Why I think it is RIFS related: On Gentoo, normaly loosing connection it is sufficient to
rc-service dhcpcd restart

But I had to do:
rc-service dhcpcd stop
rc-service wpa_supplicant restart
rc-service dhcpcd start

Which indicates a more deeply my broadcom-sta-wl module involved ...