Messages in this thread | | | Date | Sun, 09 Nov 2003 16:30:04 -0500 | From | Shailabh Nagar <> | Subject | Re: [PATCH] cfq + io priorities |
| |
Jens Axboe wrote:
>I've implemented IO nice levels in the CFQ io scheduler. > Thanks for putting this in ! It'll be very useful to have some control over I/O priorities.
>It works as >follows. > >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 ?
Of course, request sizes alone don't determine actual disk bandwidth consumed since their seek position also 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.
-- Shailabh
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |