[lkml]   [2008]   [Aug]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Too many I/O controller patches
    Dave Hansen wrote:
    > On Mon, 2008-08-04 at 17:51 +0900, Ryo Tsuruta wrote:
    >> This series of patches of dm-ioband now includes "The bio tracking mechanism,"
    >> which has been posted individually to this mailing list.
    >> This makes it easy for anybody to control the I/O bandwidth even when
    >> the I/O is one of delayed-write requests.
    > During the Containers mini-summit at OLS, it was mentioned that there
    > are at least *FOUR* of these I/O controllers floating around. Have you
    > talked to the other authors? (I've cc'd at least one of them).
    > We obviously can't come to any kind of real consensus with people just
    > tossing the same patches back and forth.
    > -- Dave


    thanks for this email first of all. I've talked with Satoshi (cc-ed)
    about his solution "Yet another I/O bandwidth controlling subsystem for
    CGroups based on CFQ".

    I did some experiments trying to implement minimum bandwidth requirements
    for my io-throttle controller, mapping the requirements to CFQ prio and
    using the Satoshi's controller. But this needs additional work and
    testing right now, so I've not posted anything yet, just informed
    Satoshi about this.

    Unfortunately I've not talked to Ryo yet. I've continued my work using a
    quite different approach, because the dm-ioband solution didn't work
    with delayed-write requests. Now the bio tracking feature seems really
    prosiming and I would like to do some tests ASAP, and review the patch
    as well.

    But I'm not yet convinced that limiting the IO writes at the device
    mapper layer is the best solution. IMHO it would be better to throttle
    applications' writes when they're dirtying pages in the page cache (the
    io-throttle way), because when the IO requests arrive to the device
    mapper it's too late (we would only have a lot of dirty pages that are
    waiting to be flushed to the limited block devices, and maybe this could
    lead to OOM conditions). IOW dm-ioband is doing this at the wrong level
    (at least for my requirements). Ryo, correct me if I'm wrong or if I've
    not understood the dm-ioband approach.

    Another thing I prefer is to directly define bandwidth limiting rules,
    instead of using priorities/weights (i.e. 10MiB/s for /dev/sda), but
    this seems to be in the dm-ioband TODO list, so maybe we can merge the
    work I did in io-throttle to define such rules.

    Anyway, I still need to look at the dm-ioband and bio-cgroup code in
    details, so probably all I said above is totally wrong...


     \ /
      Last update: 2008-08-04 20:25    [from the cache]
    ©2003-2014 Jasper Spaans. hosted at Digital Ocean