I posted a mail about an experiment on the linux generic SCSI interface:
From: GOTO Masanori <[EMAIL PROTECTED]>
Subject: linux generic SCSI interface 'READ' speed.
> I make an experiment of the simple buffering system on HDDs(cheetah)
> controling with linux generic SCSI interface.
> But, the SCSI command which is such a 'READ6' for /dev/sgX with the generic
> interface is slower than the standard C function 'read()' for /dev/sdX.
>
> Measuring difference between 'READ6' and 'read()' is below.
> This test reads 200MByte to /dev/sda sequencially from the head of HDD.
> The machine using this test is PPro with 128MByte DRAM.
(snip)
> The result is teached me that the generic SCSI interface takes 6 msec
> per one 'READ6' SCSI command.
> It seems that the kernel blocks when kernel gets the generic SCSI
> interface command.
>
> Now question:
> * How method is the generic SCSI interface to make more faster?
> * Can a program using the generic SCSI interface run with pthread?
> * Are there any way to make simple buffering system?
and have received some replies.
I made some additional experiments, and derived good results of
READ6 equivalent to read() system call with the scsi generic interface
in case of using only one disk.
In my experiments, however, I plan to use 4 disks controlled by pthreads
under the following conditions:
* The first disk do ONLY READ sequentially.
* The second disk do ONLY WRITE sequentially.
* Other disk( remaining 2 disks ) do READ/WRITE randomly.
I naturally derived good results of ONLY read or write operations on both
first and second disks.
But, the situation in which the first disk ONLY READ and the second disk
ONLY WRITE using read()/write() system call, results in enough write
performance but insufficient read.
I have checked access granularity of the file /proc/scsi/aic7xxx/x recording
read/write statistics. They indicate the access patterns as follows:
W
W
W
W
W W
---------------------------
1K 2K 4K 8K 16K 32K 64K
R R
R R R R R R
R R R R R R R
---------------------------
1K 2K 4K 8K 16K 32K 64K
While the granularity of write operations is skewed in large size,
it of read is scattered from small to large size.
I do not know how to prevent scattered access. I tried to use the scsi
generic interface which provided enough performance for only one disk,
but in case of more than two disks, too bad.
The access lamps of two disks were not lighted in the same time,
but only one lamp is lighted at a time. It's just like a seesaw.
Total access time is as twice as one disk.
Of course, I use the scsi generic interface and pthread.
Linux has the Multiple Disk Driver, which seems to achieve parallel
disk accesses with read/write...
Why don't user level programs obtain good results of accessing multiple
disks?
My goal is the parallel disk accesses by user level programming.
Are there any methods to handle parallel read/write in user mode without
scattered access?
Otherwise, should I only do rewrite kernel codes or use ioctl() to implement
my buffer system?
From: Marc SCHAEFER <[EMAIL PROTECTED]>
Subject: Re: linux generic SCSI interface 'READ' speed.
> What about trying the new direct IO on block devices (see kernel
> announcement) with a multithreaded program ?
I have tried to use RAW disk devices. But AFAIK, it handles with not
raw but ext2fs disks. The direct I/O is not useful in my goal, unfortunately.
I also know Linus dislikes to implement the raw I/O device driver.
From: Kurt Garloff <[EMAIL PROTECTED]>
Subject: Re: linux generic SCSI interface 'READ' speed.
> What comes into my mind are two things:
> a) The sd devices do buffering, readahead; adjacent reads are merged etc.
> This gives you a major speed improvement. I think you saw a speed
> improvement with using larger blocks.
> b) The sg high-level scsi code might be inefficient, i.e. locking the I/O
> for a too long time. Maybe this prevents the driver from issueing more thn
> one command at a time and such using Tagged Command queuing, when you use
> sg ?
I don't know how to read larger blocks referred to a) without scattering.
I have obtained good results by using tagged command queuing, but the queuing
has not worked well for multiple disks in my program referred to b).
From: Gerard Roudier <[EMAIL PROTECTED]>
Subject: Re: linux generic SCSI interface 'READ' speed.
> The read_block() interface prefetches up to 120 sectors = 60KB at a time
> by default for sd devices and stores the prefetched data into the buffer
> cache. So, using read() resulted in the same actual physical IO pattern
> for your 3 different logical IO patterns.
Umm... Do you know any methods to preventing read scattering?
> Despite the fact that the read_block() interface read-ahead is not
> asynchronous (no anticipated read IO that makes the C code execution
> latency overlap the IO latency), the Cheatah probably has been able
> to sustaint the read since it has a large cache and performs large
> prefetching.
>
> You got about 14 MB/s. BTW, the Cheatah2 is able to sustain about 18 MB/s.
I am using Cheetah 4LP whose data sheet specifies that the max throughput
is 14MB/sec, and I checked it out.
Regards,
--
GOTO Masanori
Tokyo Institute of Technology, Department of Computer Science
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
