Fw: [PATCH ide-dev-2.6] sata_sil: Mod15Write workaround
Oops, I forgot to cc lkml. Please cc to linux-ide@vger.kernel.org and [EMAIL PROTECTED] when replying. Sorry. - Forwarded message from Tejun Heo <[EMAIL PROTECTED]> - From: Tejun Heo <[EMAIL PROTECTED]> To: Jeff Garzik <[EMAIL PROTECTED]> Cc: linux-ide@vger.kernel.org, [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: [PATCH ide-dev-2.6] sata_sil: Mod15Write workaround X-UID: 125 X-Keywords: Hello, Jeff. I've finished the sata_sil workaround. It turned out that libata already has all the hooks needed. Although I had to twist things a bit, the workaround is completely contained inside sata_sil driver. The new work-around doesn't limit max sectors 15. All read requests and write requests <= 15 sectors are processed as-is. Write requests larger than 15 sectors are iterated inside the sata_sil driver using the ops->qc_prep and qc->complete_fn hooks. The work-around doesn't map/unmap on each iteration, it just manipulates mapped sg table and thus the PRD entries. I've been running tests (repeated mke2fs and bonnie) several hours from yesterday and it hasn't caused any problem yet. Read performance is now unhampered. Write performance doesn't look very good, but it's still much better. I'm having difficult time remembering results but on ext2, I think the write performance was better (compared to other controllers, in ratio). If you have a siimage controller and seagate drives with this problem, please don't hesitate benchmarking. Also, I think it would be very helpful if we can find out what the Windows driver is doing to work around Mod15Write. As now we can split write requests at will without affecting upper layers, we can easily replicate how they perform writes if we only know it. So, here are things I think might help. * Benchmarking new workaround. I think there should be tools better suited for this purpose than bonnie. * Benchmarking Mod15Write affected drives' read/write performance on affected siimage controllers and on other controllers on Windows. * Finding out how Windows splits write requests on affected drives. The best way would be Silicon Image coming out of the closet and tells us what they did with their Windows driver, but that doesn't seem likely. So, if somebody has the right equipment and time, please come forward and shed some light here. These sil3112/3114 controllers are way too common and so are 7200.7 Seagate drives. I was shopping for a sata add-in card last week and couldn't find any product which matches the price point of these sil controllers and ended up buying one, even knowing about the Mod15Write problem. So, I think it would be great if we can get this thing to work as fast as on Windows. So, some inputs, please. :-) Bonnie benchmark results follow and then the patch. Per-char results on P3 800 are capped by cpu, ignore them. The first one is the original sata_sil driver with max_sectors==15 work-around. The second one is with the new work-around, and the last one is on another machine with via controller. I got confused about the mount point so I'm not sure if it was a 3120026 or 3200822, but either way, you can see the write performance is way better. libata-dev-2.6 P3 800, Sil3112 rev 02, ST3120026AS === Version 1.03 --Sequential Output-- --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- MachineSize K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP 2G 9633 95 15101 24 6135 10 9975 87 14536 12 215.8 1 --Sequential Create-- Random Create -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 590 99 + +++ 27052 88 604 99 + +++ 1949 95 libata-dev-2.6 w/ workaroundP3 800, Sil3112 rev 02, ST3120026AS === Version 1.03 --Sequential Output-- --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- MachineSize K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP 2G 10606 95 23736 34 14695 19 12581 90 52786 31 218.5 1 --Sequential Create-- Random Create -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 599 99 + +++ 30161 99 579 98 + +++ 1971 97 linux-2.6.11A64 3000+, VT6420, ST3120026AS or ST3200822AS
Fw: [PATCH ide-dev-2.6] sata_sil: Mod15Write workaround
Oops, I forgot to cc lkml. Please cc to linux-ide@vger.kernel.org and [EMAIL PROTECTED] when replying. Sorry. - Forwarded message from Tejun Heo [EMAIL PROTECTED] - From: Tejun Heo [EMAIL PROTECTED] To: Jeff Garzik [EMAIL PROTECTED] Cc: linux-ide@vger.kernel.org, [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: [PATCH ide-dev-2.6] sata_sil: Mod15Write workaround X-UID: 125 X-Keywords: Hello, Jeff. I've finished the sata_sil workaround. It turned out that libata already has all the hooks needed. Although I had to twist things a bit, the workaround is completely contained inside sata_sil driver. The new work-around doesn't limit max sectors 15. All read requests and write requests = 15 sectors are processed as-is. Write requests larger than 15 sectors are iterated inside the sata_sil driver using the ops-qc_prep and qc-complete_fn hooks. The work-around doesn't map/unmap on each iteration, it just manipulates mapped sg table and thus the PRD entries. I've been running tests (repeated mke2fs and bonnie) several hours from yesterday and it hasn't caused any problem yet. Read performance is now unhampered. Write performance doesn't look very good, but it's still much better. I'm having difficult time remembering results but on ext2, I think the write performance was better (compared to other controllers, in ratio). If you have a siimage controller and seagate drives with this problem, please don't hesitate benchmarking. Also, I think it would be very helpful if we can find out what the Windows driver is doing to work around Mod15Write. As now we can split write requests at will without affecting upper layers, we can easily replicate how they perform writes if we only know it. So, here are things I think might help. * Benchmarking new workaround. I think there should be tools better suited for this purpose than bonnie. * Benchmarking Mod15Write affected drives' read/write performance on affected siimage controllers and on other controllers on Windows. * Finding out how Windows splits write requests on affected drives. The best way would be Silicon Image coming out of the closet and tells us what they did with their Windows driver, but that doesn't seem likely. So, if somebody has the right equipment and time, please come forward and shed some light here. These sil3112/3114 controllers are way too common and so are 7200.7 Seagate drives. I was shopping for a sata add-in card last week and couldn't find any product which matches the price point of these sil controllers and ended up buying one, even knowing about the Mod15Write problem. So, I think it would be great if we can get this thing to work as fast as on Windows. So, some inputs, please. :-) Bonnie benchmark results follow and then the patch. Per-char results on P3 800 are capped by cpu, ignore them. The first one is the original sata_sil driver with max_sectors==15 work-around. The second one is with the new work-around, and the last one is on another machine with via controller. I got confused about the mount point so I'm not sure if it was a 3120026 or 3200822, but either way, you can see the write performance is way better. libata-dev-2.6 P3 800, Sil3112 rev 02, ST3120026AS === Version 1.03 --Sequential Output-- --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- MachineSize K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP 2G 9633 95 15101 24 6135 10 9975 87 14536 12 215.8 1 --Sequential Create-- Random Create -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 590 99 + +++ 27052 88 604 99 + +++ 1949 95 libata-dev-2.6 w/ workaroundP3 800, Sil3112 rev 02, ST3120026AS === Version 1.03 --Sequential Output-- --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- MachineSize K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP 2G 10606 95 23736 34 14695 19 12581 90 52786 31 218.5 1 --Sequential Create-- Random Create -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 599 99 + +++ 30161 99 579 98 + +++ 1971 97 linux-2.6.11A64 3000+, VT6420, ST3120026AS or ST3200822AS
