Re: [dm-crypt] aes-xts-plain with aes_x86_64 makes my SSD 5x slower than my encrypted HD

[Milan Broz <mbroz@redhat.com>]

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