Messages in this thread | ![/](/images/icornerl.gif) | | Date | Sun, 9 Nov 2003 22:34:11 +0100 | From | Jens Axboe <> | Subject | Re: [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 ).
Done.
> 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 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/
| ![\](/images/icornerr.gif) |