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

[Corrado Zoccolo]

On Tue, Nov 24, 2009 at 2:11 PM, Alan D. Brunelle <Alan.Brunelle@xxxxxx> wrote:
> Found this whilst reviewing the CFQ I/O scheduler code: Currently, this
> routine only sorts using the I/O priority class - it does not properly
> sort prioritized queues within a specific class. The patch changes the
> sort to utilize the full I/O priority (class & priority).

This changes mixes the interpretation of classes and levels within class.
In the original code, those different things have different meanings:
* priority class decides who can use the disk
* priority level within a class determines how much of the disk time
each queue will obtain
In your case. instead, you completely remove the second meaning, and
provide a larger number of levels to just decide the first.

>
> A simple test shows the problem & fixed results: on a 16-way box, for
> each of 12 attached disks I started up 17 processes (one process at each
> possible class/priority). Each process operated on a separate file in
> the file system. I then did two types of tests: (a) direct/synchronous
> and (b) direct/asynchronous w/ an 80/20 read/write split.
>
> I then tabulated the overall I/O performed per task: (first column is
> priority class (1==RT, 2==BE, 3==IDLE), second column is the I/O
> priority (0==highest), then two groupings of read/write data moved
> (total KiBs over a span of 120 seconds):
>
> Synchronous:
> Â Â Â Â 2.6.32-rc8 Â Â 2.6.32-rc8+patch
>    ÂRead  ÂWrite   Read  ÂWrite
> Â Â ---------------- Â ----------------
> 1 0 | Â311164 Â310760 | Â424260 Â424116 |
> 1 1 | Â129712 Â129792 | Â390208 Â393232 |
> 1 2 | Â 72312 Â 71284 | Â Â 448 Â Â 420 |
> 1 3 | Â 40364 Â 41052 | Â Â Â28 Â Â Â20 |
> 1 4 | Â 26788 Â 26352 | Â Â Â28 Â Â Â24 |
> 1 5 | Â 16936 Â 16940 | Â Â Â52 Â Â Â32 |
> 1 6 | Â 11196 Â 11140 | Â Â Â28 Â Â Â20 |
> 1 7 | Â Â6476 Â Â6648 | Â Â Â20 Â Â Â28 |

The numbers for the patched kernel are bad.
All priority levels > 2 are starved. They can complete an amount of
I/O comparable with lower priority class:
> 2 0 | Â Â Â24 Â Â Â24 | Â Â Â40 Â Â Â 8 |
> 2 1 | Â Â Â24 Â Â Â24 | Â Â Â12 Â Â Â36 |
> 2 2 | Â Â Â20 Â Â Â28 | Â Â Â20 Â Â Â28 |
> 2 3 | Â Â Â28 Â Â Â20 | Â Â Â24 Â Â Â24 |
> 2 4 | Â Â Â28 Â Â Â20 | Â Â Â28 Â Â Â20 |
> 2 5 | Â Â Â28 Â Â Â20 | Â Â Â20 Â Â Â28 |
> 2 6 | Â Â Â24 Â Â Â24 | Â Â Â20 Â Â Â28 |
> 2 7 | Â Â Â24 Â Â Â24 | Â Â Â36 Â Â Â12 |
>
> 3 Â | Â Â Â36 Â Â Â12 | Â Â Â28 Â Â Â20 |
> Â Â ---------------- Â ----------------
> Sum  Â615184 Â614164  Â815300 Â818096
>
This is not the intended behaviour, and you don't need 14 priority
levels to get only one use the disk.

Cheers,
Corrado
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/