[lkml]   [2008]   [Nov]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch 0/4] [RFC] Another proportional weight IO controller
    Hi Vivek,

    Sorry for late reply.

    > > > Do you have any benchmark results?
    > > > I'm especially interested in the followings:
    > > > - Comparison of disk performance with and without the I/O controller patch.
    > >
    > > If I dynamically disable the bio control, then I did not observe any
    > > impact on performance. Because in that case practically it boils down
    > > to just an additional variable check in __make_request().
    > >
    > Oh.., I understood your question wrong. You are looking for what's the
    > performance penalty if I enable the IO controller on a device.

    Yes, that is what I want to know.

    > I have not done any extensive benchmarking. If I run two dd commands
    > without controller, I get 80MB/s from disk (roughly 40 MB for each task).
    > With bio group enabled (default token=2000), I was getting total BW of
    > roughly 68 MB/s.
    > I have not done any performance analysis or optimizations at this point of
    > time. I plan to do that once we have some sort of common understanding about
    > a particular approach. There are so many IO controllers floating, right now
    > I am more concerned if we can all come to a common platform.

    I understood the reason of posting the patch well.

    > Ryo, do you still want to stick to two level scheduling? Given the problem
    > of it breaking down underlying scheduler's assumptions, probably it makes
    > more sense to the IO control at each individual IO scheduler.

    I don't want to stick to it. I'm considering implementing dm-ioband's
    algorithm into the block I/O layer experimentally.

    Ryo Tsuruta

     \ /
      Last update: 2008-11-20 10:21    [W:0.020 / U:6.276 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site