Results 1 to 5 of 5

Thread: BFS Scheduler 0.446 Supports The Linux 3.13 Kernel

  1. #1
    Join Date
    Jan 2007
    Posts
    14,529

    Default BFS Scheduler 0.446 Supports The Linux 3.13 Kernel

    Phoronix: BFS Scheduler 0.446 Supports The Linux 3.13 Kernel

    For users of the BFS scheduler patches to the kernel, they have been updated this week for the Linux 3.13 kernel...

    http://www.phoronix.com/vr.php?view=MTYyMzA

  2. #2
    Join Date
    Dec 2012
    Posts
    524

    Default

    Just curious, to anyone who uses the ck or pf patchesets, do the bfs schedulers actually help fix that annoying "disk io (especially usb interrupt based) makes the system unresponsive" mess that happens on generic kernels? I'm finding myself doing a lot more large file transfers at 300+ MB/s and it cripples even my i7 rig for their duration.

  3. #3
    Join Date
    Jul 2012
    Posts
    727

    Default

    Quote Originally Posted by zanny View Post
    Just curious, to anyone who uses the ck or pf patchesets, do the bfs schedulers actually help fix that annoying "disk io (especially usb interrupt based) makes the system unresponsive" mess that happens on generic kernels? I'm finding myself doing a lot more large file transfers at 300+ MB/s and it cripples even my i7 rig for their duration.
    BFS doesn't affect your disk. It's a CPU scheduler. You'd have to use BFQ for that and enable it with "elevator=bfq" in the kernel line first. Apparently it is designed to keep the system responsive at all times.
    https://www.youtube.com/watch?v=J-e7LnJblm8
    Last edited by blackout23; 03-06-2014 at 10:11 AM.

  4. #4
    Join Date
    Jan 2009
    Location
    Vienna, Austria; Germany; hello world :)
    Posts
    628

    Default

    Quote Originally Posted by zanny View Post
    Just curious, to anyone who uses the ck or pf patchesets, do the bfs schedulers actually help fix that annoying "disk io (especially usb interrupt based) makes the system unresponsive" mess that happens on generic kernels? I'm finding myself doing a lot more large file transfers at 300+ MB/s and it cripples even my i7 rig for their duration.
    it mitigates things but, of course, doesn't fix a problem, that isn't caused by or inherent to the cpu scheduling part

    "disk io (especially usb interrupt based) makes the system unresponsive"

    so how exactly does this show itself ?

    you have an SSD or raid harddrive enclosure attached to the USB 3.0 ports ? (referring to the usb interrupt part)


    will post some tweaks once I'm on linux again, currently on Windows - gaming some (Origin doesn't allow to install Mass Effect 3 & other games also don't work)

  5. #5
    Join Date
    Jan 2009
    Location
    Vienna, Austria; Germany; hello world :)
    Posts
    628

    Default

    Quote Originally Posted by kernelOfTruth View Post
    it mitigates things but, of course, doesn't fix a problem, that isn't caused by or inherent to the cpu scheduling part

    "disk io (especially usb interrupt based) makes the system unresponsive"

    so how exactly does this show itself ?

    you have an SSD or raid harddrive enclosure attached to the USB 3.0 ports ? (referring to the usb interrupt part)


    will post some tweaks once I'm on linux again, currently on Windows - gaming some (Origin doesn't allow to install Mass Effect 3 & other games also don't work)


    Code:
    echo "raise latency_timer for EHCI USB2.0"
    # raise priority of others:
    setpci -v -s 00:1a.0 latency_timer=80 # EHCI USB2.0
    setpci -v -s 00:1d.0 latency_timer=80 # EHCI USB2.0
    <-- of course modify according to your lspci output

    Code:
    echo 15 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
    echo 10 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor

    make sure that the:
    Code:
    dirty_expire_centisecs
    dirty_writeback_centisecs
    dirty_background_ratio
    dirty_ratio
    values are not too high


    make sure the (and more) following patchsets are included in your kernel:

    - [patch 0/2] mm: reduce reclaim stalls with heavy anon and dirty cache
    - mm: add strictlimit knob; http://article.gmane.org/gmane.linux.kernel.mm/105809

Posting Permissions

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