Andrew Morton wrote:
>
> I'll test scsi now.
>
aic7xxx, Fujitsu "MAF3364L SUN36G" (36G SCA-2)
Maximum number of TCQ tags=253
fifo_batch time cat kernel/*.c (seconds)
64 58
32 54
16 20
8 58
4 1:15
2 53
Maximum number of TCQ tags=4
fifo_batch time cat kernel/*.c (seconds)
64 53
32 39
16 33
8 21
4 22
2 36
1 22
Maximum number of TCQ tags = 0:
fifo_batch time cat kernel/*.c (seconds)
64 22
32 10.3
16 10.5
8 5.5
4 3.2
2 1.9
I selected fifo_batch=16 and altered writes_starved and read_expires
again. They made no appreciable difference.
>From this I can only conclude that my poor little read was stuck
in the disk for ages while TCQ busily allowed new incoming writes
to bypass already-sent reads.
A dreadful misdesign. Unless we can control this with barriers,
and if Fujutsu is typical, TCQ is just uncontrollable. I, for
one, would not turn it on in a pink fit.
-
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/
This archive was generated by hypermail 2b29 : Mon Sep 30 2002 - 22:00:25 EST