lkml.org 
[lkml]   [2016]   [Oct]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra scheduler
    From
    Date

    > Il giorno 26 ott 2016, alle ore 17:32, Jens Axboe <axboe@kernel.dk> ha scritto:
    >
    > On 10/26/2016 09:29 AM, Christoph Hellwig wrote:
    >> On Wed, Oct 26, 2016 at 05:13:07PM +0200, Arnd Bergmann wrote:
    >>> The question to ask first is whether to actually have pluggable
    >>> schedulers on blk-mq at all, or just have one that is meant to
    >>> do the right thing in every case (and possibly can be bypassed
    >>> completely).
    >>
    >> That would be my preference. Have a BFQ-variant for blk-mq as an
    >> option (default to off unless opted in by the driver or user), and
    >> not other scheduler for blk-mq. Don't bother with bfq for non
    >> blk-mq. It's not like there is any advantage in the legacy-request
    >> device even for slow devices, except for the option of having I/O
    >> scheduling.
    >
    > It's the only right way forward. blk-mq might not offer any substantial
    > advantages to rotating storage, but with scheduling, it won't offer a
    > downside either. And it'll take us towards the real goal, which is to
    > have just one IO path.

    ok

    > Adding a new scheduler for the legacy IO path
    > makes no sense.

    I would fully agree if effective and stable I/O scheduling would be
    available in blk-mq in one or two months. But I guess that it will
    take at least one year optimistically, given the current status of the
    needed infrastructure, and given the great difficulties of doing
    effective scheduling at the high parallelism and extreme target speeds
    of blk-mq. Of course, this holds true unless little clever scheduling
    is performed.

    So, what's the point in forcing a lot of users wait another year or
    more, for a solution that has yet to be even defined, while they could
    enjoy a much better system, and then switch an even better system when
    scheduling is ready in blk-mq too?

    For example, currently, opening a terminal on a 50KIOPS SSD with cfq,
    deadline or noop, if there happens to be some background workload,
    takes *more* time than opening the same terminal on a 1KIOPS HDD with
    the same background workload, but with BFQ. Does this make any sense?

    > Adding one for blk-mq and phasing out the old path is
    > what we need to do.
    >

    Yes, as the ultimate goal.

    Thanks,
    Paolo

    > --
    > Jens Axboe
    >

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