lkml.org 
[lkml]   [2016]   [Oct]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH V3 00/11] block-throttle: add .high limit
    On Tue, Oct 4, 2016 at 9:14 PM, Tejun Heo <tj@kernel.org> wrote:

    > I get that bfq can be a good compromise on most desktop workloads and
    > behave reasonably well for some server workloads with the slice
    > expiration mechanism but it really isn't an IO resource partitioning
    > mechanism.

    Not just desktops, also Android phones.

    So why not have BFQ as a separate scheduling policy upstream,
    alongside CFQ, deadline and noop?

    I understand the CPU scheduler people's position that they want
    one scheduler for everyone's everyday loads (except RT and
    SCHED_DEADLINE) and I guess that is the source of the highlander
    "there can be only one" argument, but note this:

    kernel/Kconfig.preempt:

    config PREEMPT_NONE
    bool "No Forced Preemption (Server)"
    config PREEMPT_VOLUNTARY
    bool "Voluntary Kernel Preemption (Desktop)"
    config PREEMPT
    bool "Preemptible Kernel (Low-Latency Desktop)"

    We're already doing the per-usecase Kconfig thing for preemption.
    But maybe somebody already hates that and want to get rid of it,
    I don't know.

    Yours,
    Linus Walleij

    \
     
     \ /
      Last update: 2016-10-06 10:05    [W:2.908 / U:0.068 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site