Hello, from kernel 2.6.33 on (at least up to 2.6.37) the access time when using dm-crypt on SSD is way too high. I would expect it to be a bit worse than directly accessing the device (~0.2ms here), but currently it's at exactly 10ms (except a few outlines). This corresponds to CONFIG_HZ=100. The high access time makes the system feel very slow (if you're expecting SSD performance). On kernel 2.6.32 this wasn't an issue, access time stayed below 0.3ms. Those numbers are from palimpsest, but the difference is so drastic, that pretty much everything you can think of shows a difference (e. g. find-ing all files on the disk goes up from tens of seconds to multiple minutes). Just to be clear: This isn't about a dm-crypt encrypted disk being slower that an unencrypted disk. It's about the access time of the same encrypted disk rising to >= 10ms, which is at least an order of magnitude for an SSD. I suspect with an HDD, the difference isn't much noticeable. I filed a bugreport on the Ubuntu bugtracker with a few pretty graphs, vmstat and LatencyTOP output. If that would be useful, see https://bugs.launchpad.net/ubuntu/+source/linux/+bug/653611 . A bisect between .32 and .33 revealed some more information. I arrived at 79da064, which is a revert of fb1e753 (block: improve queue_should_plug() by looking at IO depths), so I compiled fb1e753. With this 2.6.31 kernel, the problem was gone. One step back to 1f98a13, the access time was high again. So, it seems that fb1e753 (block: improve queue_should_plug() by looking at IO depths) improves dm-crypt access time on SSDs (by a factor of over 40 here), but (as in the revert commit stated) reduces sequential throughput in some cases. I applied fb1e753 to 2.6.37 and the access time went down to the .32 value. For me, it seems that dm-crypt interferes with queuing, which totally destroys access time. If the disk empties the queue after a few fractions of a millisecond, and it only gets refilled every tick (10ms), wouldn't this explain the observed behavior? Correspondingly, a 300HZ kernel achieves about 3ms access time Going all the way up to 1000HZ hardly improves that number. Please keep me on CC, since I am not subscribed. Thanks Michael -- To unsubscribe from this list: send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
