On 07/23/2012 06:12 PM, Marc MERLIN wrote: > On Mon, Jul 23, 2012 at 10:14:07AM +0200, Arno Wagner wrote: > (editted: actually no, using 'null' encryptino still gives 25MB/s). Ok, the we can forget about aes-ni etc, it is problem somewhere else. > Mmmh, I have one possible thing. I have a preempt kernel. Could that be it? > http://marc.merlins.org/tmp/config-3.4.4-amd64-preempt.txt Can you send me your kernel .config then? Preempt should not be problem. Which kernel version? which architecture? Any additional patches over mainline code? >> Paste fdisk -l -u /dev/sda > > Disk /dev/sda: 512.1 GB, 512110190592 bytes > 255 heads, 63 sectors/track, 62260 cylinders, total 1000215216 sectors > Units = sectors of 1 * 512 = 512 bytes > Sector size (logical/physical): 512 bytes / 512 bytes > I/O size (minimum/optimal): 512 bytes / 512 bytes > Disk identifier: 0x09aaf50a > > Device Boot Start End Blocks Id System > /dev/sda1 * 2048 502047 250000 83 Linux > /dev/sda2 502048 52930847 26214400 83 Linux > /dev/sda3 52930848 73902367 10485760 82 Linux swap / Solaris > /dev/sda4 73902368 1000215215 463156424 83 Linux Hm. sda1 is apparently aligned. But I think other partitions are not aligned properly. No idea which block size/page size your SSD internaly use, but to be safe, let's assume ideal is 256KiB (= 512 * 512 byte sectors). 73902368 seems not to be multiple of 512... Well, your sda2 configuration is created with +256MB, which is SI unit, so not multiple of 1024 but 1000! It should be created with +256M, so you end with: Device Boot Start End Blocks Id System /dev/sda1 2048 526335 262144 83 Linux /dev/sda2 526336 ... But I think this is not the core problem but you should try it to fix. (I hope I did not mixed up numbers above :) ... Thinking about it, we can test it without partition change (for reads). This test is perhaps useless but maybe someone can find it useful later. Let's map properly aligned device to sda4 (read only). Result will be just garbage, but it is just for speed testing. For mapping above, properly aligned (1MiB alignment = 2048 sectors) should start on sector 7390412. This is +1760 sector shift for sda4. Map 1GiB device there: # dmsetup create test_plain -r --table "0 2097152 linear /dev/sda4 1760" Map null cryptsetup over it # echo "password" | cryptsetup create -c null test_crypt /dev/mapper/test_plain Now repeat read dd test for /dev/mapper/test_plain and /dev/mapper/test_crypt Still the same slow down? Remove devices # dmsetup remove test_crypt # dmsetup remove test_plain (Btw if you use real cipher and zero device instead of underlying disk, you can measure encryption throughput: # dmsetup create test_plain --table "0 2097152 zero" # echo "password" | cryptsetup create -c aes-xts-plain64 -s 256 test_crypt /dev/mapper/test_plain ... very useful to prove that your cpu encryption is slow... but we proved that it is not the case here, so just for the archive :-) > I also used: > cryptsetup luksFormat --align-payload=8192 It will not help if underlying partition is misaligned. >> 2) try to switch io scheduler to "noop" or "deadline" > But just to make sure, I tried cfg, noop, and deadline and it didn't make a > difference. ok >> Also you can try to increase queue size. > > Not sure which one it is: I think this one, try to increase it to 8192 or so... > nr_requests:128 Milan _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
