On Wed, 2008-11-12 at 02:47 -0800, bugme-daemon@xxxxxxxxxxxxxxxxxxx wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=11898 > > > > > > ------- Comment #37 from vandrove@xxxxxxxxxx 2008-11-12 02:47 ------- > Patch from #36 fixes hangs & crashes. Thanks. Great, thanks! > So only remaining problem (for me...) is that with default setup I'm now > getting only 50% of throughput I was getting with 2.6.27 - I can get ~40% back > by limiting disks to 8 requests (so 31 per SATA controller is not hit that > frequently), at the cost of making random I/O much worse... Here are > sequential write data (dd if=/dev/zero of=/xxx) - with default setting ~25MBps > * 4, with restricting disks to 8 commands ~39MBps * 4. 2.6.27 gets ~47MBps * > 4, and 2.6.27 with sata_sil24 patch to increase PCIe read length gets ~51MBps * > 4 (which is present in current git tree tested here). > > Default setting: > > gwy:~# ./x.sh > 4000+0 records in > 4000+0 records out > 4194304000 bytes (4.2 GB) copied, 110.417 s, 38.0 MB/s > gwy:~# 4000+0 records in > 4000+0 records out > 4194304000 bytes (4.2 GB) copied, 155.827 s, 26.9 MB/s > 4000+0 records in > 4000+0 records out > 4194304000 bytes (4.2 GB) copied, 206.971 s, 20.3 MB/s > 4000+0 records in > 4000+0 records out > 4194304000 bytes (4.2 GB) copied, 206.301 s, 20.3 MB/s > > Only 8 requests per drive; there are 4 drives sharing one tag map with 31 > entries: > > gwy:~# for a in /sys/block/*/queue/nr_requests; do echo 8 > $a; done > gwy:~# ./x.sh > 4000+0 records in > 4000+0 records out > 4194304000 bytes (4.2 GB) copied, 103.588 s, 40.5 MB/s > gwy:~# 4000+0 records in > 4000+0 records out > 4194304000 bytes (4.2 GB) copied, 110.86 s, 37.8 MB/s > 4000+0 records in > 4000+0 records out > 4194304000 bytes (4.2 GB) copied, 105.978 s, 39.6 MB/s > 4000+0 records in > 4000+0 records out > 4194304000 bytes (4.2 GB) copied, 107.94 s, 38.9 MB/s Um, you might want to report this one separately. I'd suggest to both the IDE and SCSI lists: linux-scsi@xxxxxxxxxxxxxxx linux-ide@xxxxxxxxxxxxxxx Appending it to a bug report we're getting ready to close is a sure way of losing the information. James -- 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
