[1508] in linux-scsi channel archive
Re: elevator sorting for the scsi subsystem.
daemon@ATHENA.MIT.EDU (Leonard N. Zubkoff)
Tue Mar 4 06:21:11 1997
Date: Tue, 4 Mar 1997 02:46:07 -0800
From: "Leonard N. Zubkoff" <lnz@dandelion.com>
To: Dario_Ballabio@milano.europe.dg.com
CC: linux-scsi@vger.rutgers.edu, groudier@club-internet.fr
In-reply-to: <199703030918.KAA10307@milano.europe.dg.com>
(Dario_Ballabio@milano.europe.dg.com)
Date: Mon, 3 Mar 1997 10:18:55 +0100
From: Dario_Ballabio@milano.europe.dg.com
3) This point can be defined by a suitable benchmark. I know exactely
what a software implementation of the elevator sorting can provide.
I'm doing random reads, 512 bytes each, over 960000 sectors. The
unsorted average seek distance is 320000 sectors. If the device
queue depth is 15 and there are 15 processes doing the above work,
the elevator sorted average seek distance is 67000 sectors. The
gain in term of seek reduction is 5:1. In this condition no sort
is performed by ll_rw_blk. I would like to see results of the
above benchmark using SIMPLE QUEUE TAGS first and ORDERED QUEUE
TAGS next for all the operations. This allows us to evaluate out
of any discussion the benefits of the current implementation
where all the optimization is left to the scsi drive.
Anybody willing to perform such a benchmark and let us know the
results?
I'm afraid I don't have a benchmark that directly responds to your request, but
I do have some sample data on the performance of tagged queuing. The
experiment is to execute a continuous sequence of random (across the entire
disk) or sequential (from the beginning of the disk) read or write commands to
the disk keeping a constant queue depth. As each command completes a new one
is immediately issued to keep the queue depth close to constant. Each
experiment is executed for 20 or 30 seconds, and the I/O rate in operations per
second is reported as a function of the queue depth (QD in the table below).
This works through the SCSI level directly, so there is no sorting in the
kernel of any kind. The data is primarily Simple Queue Tags, with an Ordered
Queue tag thrown in every 3 seconds or so by the driver to avoid starvation.
If only Ordered Queue Tags were used, then we'd be in the QD = 1 case since the
drive wouldn't be allowed to do any optimization.
Will your data translate into I/O rates?
Leonard
***** Random Read Test (20.00 seconds) *****
Total Total Total sdb
BlkSize QD CPU int/s ops/s bytes/sec op/s
======= == === ===== ===== ========= ====
512 1 1% 70 70 35651 70
512 2 0% 77 77 39333 77
512 3 0% 76 76 39052 76
512 4 0% 88 88 44864 88
512 5 1% 96 96 49184 96
512 6 1% 101 101 51583 101
512 7 1% 106 106 54440 106
512 8 1% 110 110 56478 110
512 9 1% 114 114 58135 114
512 10 1% 115 115 59079 115
512 11 1% 118 118 60671 118
512 12 1% 121 121 61740 121
512 13 1% 124 124 63561 124
512 14 1% 126 126 64363 126
512 15 1% 128 128 65360 128
512 16 1% 128 128 65378 128
512 17 1% 131 131 67318 131
512 18 1% 130 130 66710 130
512 19 1% 133 133 67970 133
512 20 1% 133 133 68326 133
512 21 1% 137 137 70371 137
512 22 1% 137 137 70035 137
512 23 1% 138 138 70768 138
512 24 1% 140 140 71442 140
512 25 1% 141 141 72090 141
512 26 1% 142 142 72683 142
512 27 1% 143 143 73443 143
512 28 1% 143 143 73002 143
512 29 1% 144 144 73939 144
512 30 1% 145 145 74031 145
512 31 1% 145 145 74487 145
