Re: [PATCH 0/1] Correct sorting problem in cfq_service_tree_add

[Corrado Zoccolo <czoccolo@gmail.com>]

Hi Alan,
On Tue, Nov 24, 2009 at 3:49 PM, Alan D. Brunelle <Alan.Brunelle@hp.com> wrote:
>
> Having read the ioprio.txt I had thought that the priorities within a
> class should still be honored and that the time slice calculations in
> cfq_prio_slice would be left as is. "ioprio" is probably the wrong field
> name in the code (and text) then, as it is not meant as a priority but
> as a time slice indicator?! The text in ioprio.txt and in the man page
> for ionice are very inconsistent here: For example, the ionice man page
> states: "This [best effort] class takes a priority argument from 0-7,
> with lower number being higher priority. Programs running at the same
> best effort priority are served in a round-robin fashion." Which implies
> a secondary sort-order for priority within a class. Of course, both
> ioprio.txt and the ionice man page also talk about class levels in a way
> that may indicate it is not priority based. Hm...

ionice man page is usually not in sync with the kernel. It should
really just point at the kernel doc, since it is just an interface to
set up parameters, that will then be interpreted by the kernel (or
list the different interpretations for those at each kernel
incarnation, but this is infeasible).

ioprio.txt in my kernel tree says quite explicitly that RT can starve
BE, and IDLE is starved by anyone.
Moreover, it says:
RT: Within the RT class, there are 8 levels of class data that
determine exactly how much time this process needs the disk for on
each service.
BE: The class data determines how much io bandwidth the process will
get, it's directly mappable to the cpu nice levels just more coarsely
implemented. 0 is the highest BE prio level, 7 is the lowest.

This is still a bit confusing, since it says disk time for RT and bw
for BE, while the implementation is the same for both, time based.

BTW, if you want to review CFQ, you should look at
http://git.kernel.dk/?p=linux-2.6-block.git;a=shortlog;h=refs/heads/for-2.6.33,
where cfq development for next kernel version is taking place.

Thanks
Corrado