[lkml]   [2003]   [Nov]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] cfq + io priorities
    On Sun, Nov 09 2003, Shailabh Nagar wrote:
    > >A process has an assigned io nice level, anywhere from 0 to 20. Both of
    > >these end values are "special" - 0 means the process is only allowed to
    > >do io if the disk is idle, and 20 means the process io is considered
    > >realtime. Realtime IO always gets first access to the disk.
    > >
    > >Values from 1 to 19 assign 5-95% of disk bandwidth to that process. Any io
    > >class is
    > >allowed to use all of disk bandwidth in absence of higher priority io.
    > >
    > >
    > Currently, cfq is doing bandwidth allocation in terms of number of
    > requests, not bytes. Hence priority inversion can happen if lower
    > priority levels submit larger requests on an average. Any plans to take
    > request sizes into consideration in future ?

    Yes that needs to be taken into account as well. I'll get another
    version out soonish that works around that too.

    > Of course, request sizes alone don't determine actual disk bandwidth
    > consumed since their seek position also matters.

    Yeah that's where it gets tricky. It's basically impossible to get
    absolutely right, it will always be just guidelines. I don't want to
    over complicate matters.

    > >About the patch: stuff like this really needs some resource management
    > >abstraction like CKRM. Right now we just look at the tgid of the
    > >process.
    > >
    > Now thats music to our ears :-) Though you've complicated matters by
    > calling the priority level a "class" ! Please consider renaming
    > class to something else (say priolevel ).


    > Thanks for separating the hashvalue as a macro. It should make it even
    > easier to convert cfq to use a CKRM I/O classes ' priority
    > rather than the submitting task's ioprio value.

    Yup that was my intention, to make the transition as smooth as possible.

    Jens Axboe

    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: 2005-03-22 13:58    [W:0.025 / U:8.432 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site