lkml.org 
[lkml]   [2014]   [May]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH RFC RESEND 00/14] New version of the BFQ I/O Scheduler
    On Tue, May 27, 2014 at 02:42:24PM +0200, paolo wrote:

    [..]
    > Strong fairness guarantees (already provided by BFQ-v0)
    >
    > As for long-term guarantees, BFQ distributes the device throughput
    > (and not just the device time) as desired to I/O-bound applications,
    > with any workload and regardless of the device parameters.

    I don't think most of the people care about strong fairness guarantee.
    As an algorithm round robin is not bad for ensuring fairness. CFQ had
    started with that but then it stopped focussing on fairness and rather
    focussed on trying to address various real issues.

    And CFQ's problems don't arise from not having a good fairness algorithm.
    So I don't think this should be the reason for taking a new scheduler.

    I think instead of numbers, what would help is a short description
    that what's the fundamental problem with CFQ which BFQ does not
    have and how did you solve that issue.

    One issue you seemed to mention is that write is a problem. CFQ
    suppresses buffered writes very actively in an attempt to improve
    read latencies. How did you make it even better with BFQ.

    Last time I had looked at BFQ, it looked pretty similar to CFQ except
    that core round robin algorithm had been replaced by a more fair
    algo and more things done like less preemption etc.

    But personally I don't think using a more accurate fairness algorithm
    is the problem to begin with most of the time.

    So I fail to understand that why do we need BFQ.

    Thanks
    Vivek


    \
     
     \ /
      Last update: 2014-05-30 21:41    [W:2.331 / U:0.064 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site