Hi Matthew and Kashyap, Thanks for your comments! On Tue, Dec 1, 2009 at 1:11 AM, Matthew Wilcox <matthew@xxxxxx> wrote: > On Mon, Nov 30, 2009 at 08:07:58PM +0530, Desai, Kashyap wrote: >> > for i in 1 4 16 64 256 512 1024 2048 4096 8192 16384 32768 65536; do >> > bs=$((BS * i)) >> > count=$((COUNT / i)) >> > >> > echo bs=$bs count=$count >> > sudo mount /dev/sdb1 /media/test >> > dd if=/dev/zero of=/media/test/foo bs=$bs count=$count >> > sudo umount /media/test >> > sleep 1 >> > sudo mount /dev/sdb1 /media/test >> > dd if=/media/test/foo of=/dev/null bs=$bs count=$count >> Replace /media/test/foo with /dev/sdb1, you will see raw read >> > rm /media/test/foo >> > sudo umount /media/test >> > done >> > >> This test is not purely RAW read/write test. In you test File system performance is also included. While read operation, (sequential read) File system buffering will give huge advantage to data transfer. > > Both filesystem and block access will use the page cache. You should > use iflag=direct (or oflag=direct as appropriate) in order to bypass > the page cache. > > -- > Matthew Wilcox Intel Open Source Technology Centre > "Bill, look, we understand that you're interested in selling us this > operating system, but compare it to ours. We can't possibly take such > a retrograde step." > The bottleneck is in the file system. I retried dd with the direct I/O option. The performance improves with large block sizes. The cross point is about 256 KB. bs write (MB/s) read (MB/s) 1024 9.5 9.7 4096 34.4 28.3 16384 95.8 47.0 65536 186 121 262144 382 307 524288 417 366 1048576 449 380 2097152 497 467 4194304 511 532 8388608 498 560 16777216 523 545 33554432 555 541 67108864 554 543 My page is also updated. Best regards, Ryousei -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html