[lkml]   [2006]   [Oct]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Bandwidth Allocations under CFQ I/O Scheduler
    On Tue, Oct 17, 2006 at 03:23:13PM +0200, Jens Axboe wrote:
    > On Tue, Oct 17 2006, Arjan van de Ven wrote:
    > > Hi,
    > >
    > > it's a nice idea in theory. However... since IO bandwidth for seeks is
    > > about 1% to 3% of that of sequential IO (on disks at least), which
    > > bandwidth do you want to allocate? "worst case" you need to use the
    > > all-seeks bandwidth, but that's so far away from "best case" that it may
    > > well not be relevant in practice. Yet there are real world cases where
    > > for a period of time you approach worst case behavior ;(
    > Bandwidth reservation would have to be confined to special cases, you
    > obviously cannot do it "in general" for the reasons Arjan lists above.

    How about allocating I/O operations instead of bandwidth ?

    So, any read is really a seek+read, and we count that as one I/O
    operation. Same for writes.

    Since the total "capacity" of the system is typically (in real-world
    scenarios) the number of operations (seek+X) rather than the raw
    sequential bandwidth anyway, I suppose that I/O operations would be what
    you wanted to allocate anyway.

    Anyway, just a thought...

    (And if you're thinking one sequential reader/writer could then starve
    the system; well, count every 256KiB of data to read/write as a seperate
    I/O operation even though no seek is needed. That would very roughly
    match the raw read/write performance with the seek performance)


    / jakob

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-10-18 10:03    [W:0.020 / U:19.916 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site