Page 3 of 15 FirstFirst 1234513 ... LastLast
Results 21 to 30 of 150

Thread: RIFS-ES Linux Kernel Scheduler Released

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

    Default

    Quote Originally Posted by ulenrich View Post
    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)
    Last edited by 3766691; 06-21-2012 at 11:36 AM.

  2. #22
    Join Date
    Oct 2011
    Posts
    56

    Default

    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

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

    Default

    Quote Originally Posted by ulenrich View Post
    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.
    Last edited by 3766691; 06-21-2012 at 06:15 PM.

  4. #24
    Join Date
    May 2012
    Location
    GuangDong,China
    Posts
    141

    Default

    Quote Originally Posted by 3766691 View Post
    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!!!

  5. #25
    Join Date
    Oct 2011
    Posts
    56

    Default

    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!

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

    Default

    Quote Originally Posted by ulenrich View Post
    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.

  7. #27
    Join Date
    Mar 2011
    Posts
    378

    Default

    Quote Originally Posted by 3766691 View Post
    Also I have finished the porting of 3.5.x kernel.
    Would you please share the patch? Would love to test it.

  8. #28
    Join Date
    Jan 2009
    Location
    Vienna, Austria; Germany; hello world :)
    Posts
    637

    Default

    Quote Originally Posted by TAXI View Post
    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

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

    Default

    Quote Originally Posted by kernelOfTruth View Post
    ++

    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.

  10. #30
    Join Date
    Oct 2011
    Posts
    56

    Default one sleepy thing

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

Posting Permissions

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