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 01:09 PM, Yves-Alexis Perez wrote:
> On lun., 2012-07-23 at 12:46 +0200, Milan Broz wrote:
>> So no wonder that you get slow operation - in dd/hdparm usually only
>> one cpu is processing the request. If CPU is fast enough, no problem.
>> If not you will see slowdown. AES-NI will speed up this on that cpu
>> core,
>> but will not help run request in parallel on multi-core systems.
> 
> Then I should see slow operations too, since I'm doing exactly the same
> test. My guess is that is a kernel issue somewhere, but maybe we should
> try a common ground (say, a grml live or some fedora live) and report
> back?

Well, yes. I explained dmcrypt part, there can be other problem.
E.g. alignment (bit it _seems_ correct from mails).

Reading again, 23MB/s is really slow, so yes there must be something else.

Common distro env is nice but be sure you have proper crypto modules available.
Also do not use Fedora rawhide, it has kernel compiled with debug tools
not usable for testing.

You can try start with this:

1) (this should be not problem but better check it)
Check alignment of partitions. Is it aligned to SSD page size?
(Aligning to 1MiB is always correct ;-)
Paste fdisk -l -u /dev/sda


2) try to switch io scheduler to "noop" or "deadline"
(paste lsblk -t)

You can do it online for sda (again, check with lsblk -t):
echo "noop">/sys/block/sda/queue/scheduler

Also you can try to increase queue size.

(Hard core version is to run blktrace and check if request are not split
unnecessarily :)

3) Let's test cipher_null (no encryption just fake-copy)
(you need cryptsetup 1.4.3 for this test).

create test LUKS device with null cipher: cryptsetup luksFormat -c null

Repeat tests now - is the problem the same? (please send output).
(For dmcrypt device speed should be only slighly slower.)

please note: cipher null means no encryption, just use dmcrypt layer,
so do not use for valid data :-)

4) which aes module are you using? check lsmod, check /proc/crypto

you should use either aes-ni or optimized modules (x86_64 etc)

Milan
p.s.
sorry for removing cc on first reply, my mistake.