On Sat, Nov 28, 2015 at 11:38 AM, Christoph Anton Mitterer <cales...@scientia.net> wrote: > On Sat, 2015-11-28 at 11:34 -0700, Chris Murphy wrote: >> It sounds to me like maybe LUKS is configured to use an encryption >> algorithm that isn't subject to CPU optimized support, e.g. aes-xts >> on >> my laptop gets 1600MiB/s where serpent-cbc gets only 68MiB/s and pegs >> the CPU. This is reported by 'cryptsetup benchmark' > > hmmm... > $ /sbin/cryptsetup benchmark > # Tests are approximate using memory only (no storage IO). > PBKDF2-sha1 910222 iterations per second > PBKDF2-sha256 590414 iterations per second > PBKDF2-sha512 399609 iterations per second > PBKDF2-ripemd160 548418 iterations per second > PBKDF2-whirlpool 179060 iterations per second > # Algorithm | Key | Encryption | Decryption > aes-cbc 128b 474,3 MiB/s 1686,2 MiB/s > serpent-cbc 128b 69,4 MiB/s 235,3 MiB/s > twofish-cbc 128b 144,5 MiB/s 271,6 MiB/s > aes-cbc 256b 348,0 MiB/s 1239,4 MiB/s > serpent-cbc 256b 68,8 MiB/s 231,5 MiB/s > twofish-cbc 256b 146,6 MiB/s 268,9 MiB/s > aes-xts 256b 1381,3 MiB/s 1384,3 MiB/s > serpent-xts 256b 238,6 MiB/s 231,1 MiB/s > twofish-xts 256b 262,9 MiB/s 266,7 MiB/s > aes-xts 512b 1085,7 MiB/s 1078,9 MiB/s > serpent-xts 512b 242,1 MiB/s 230,2 MiB/s > twofish-xts 512b 266,8 MiB/s 265,9 MiB/s > > I'm having aes-xts-plain64 with 512 bit key... > that's still 1 GiB/s
I'm using aes-xts-plain64 with a 512 bit keysize also, and dmcrypt doesn't even register in iotop or top when I do a scrub of the file system. So I'm not sure what's going on in your case. But I also don't use compression. The apparent fragmentation is actually bogus, it's an artifact of compression. If you look at the fragments with filefrag -v, you'll see that these are actually contiguous extents for the most part. -- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
