From: Marc MERLIN <marc@merlins.org>
To: Milan Broz <mbroz@redhat.com>, Yves-Alexis Perez <corsac@debian.org>
Cc: dm-crypt@saout.de
Subject: Re: [dm-crypt] aes-xts-plain with aes_x86_64 makes my SSD 5x slower than my encrypted HD
Date: Mon, 23 Jul 2012 10:51:29 -0700 [thread overview]
Message-ID: <20120723175129.GA15867@merlins.org> (raw)
In-Reply-To: <1343060350.26887.20.camel@scapa> <500D86AC.7090100@redhat.com>
On Mon, Jul 23, 2012 at 07:15:24PM +0200, Milan Broz wrote:
> > 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?
I just sent you my config, it was in the URL above :)
No patches, kernel 3.4.4 from kernel.org, see above.
I tried without preempt and with volprempt and duplicated the same slow
speeds.
> > 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.
Really?
I used fdisk -H32 -S32 /dev/sda as recomended on
http://www.void.gr/kargig/blog/2012/01/11/linux-ssd-partition-alignment-tips/
> 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!
Oh my, I can't believe they changed that (been using linux since 1993 back
then +1MB in fdisk was a real MB).
> 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 :)
It would be a problem for erase blocks if it is wrong, but not for reading,
especially when I can do filesystem reads at 260MB/s on the filesystem
created on the encrypted device.
But I'm confused, I thought
fdisk -H32 -S32
would protect me from mis-alignment and fdisk/util-linux 2.20.1 was smart
enough to use proper boundaries on its own on SSDs anyway.
> ... 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
Same thing:
gandalfthegreat:~# dmsetup create test_plain -r --table "0 2097152 linear /dev/sda4 1760"
gandalfthegreat:~# echo "password" | cryptsetup create -c null test_crypt /dev/mapper/test_plain
gandalfthegreat:~# dmsetup status test_crypt
0 2097152 crypt
gandalfthegreat:~# cryptsetup status test_crypt
/dev/mapper/test_crypt is active.
type: PLAIN
cipher: cipher_null-ecb
keysize: 0 bits
device: /dev/mapper/test_plain
offset: 0 sectors
size: 2097152 sectors
mode: read/write
gandalfthegreat:~# hdparm -t -T /dev/mapper/test_plain
/dev/mapper/test_plain:
Timing cached reads: 13978 MB in 2.00 seconds = 6997.30 MB/sec
Timing buffered disk reads: 958 MB in 3.00 seconds = 319.00 MB/sec
gandalfthegreat:~# hdparm -t -T /dev/mapper/test_crypt
/dev/mapper/test_crypt:
Timing cached reads: 15434 MB in 2.00 seconds = 7725.50 MB/sec
Timing buffered disk reads: 76 MB in 3.03 seconds = 25.05 MB/sec
gandalfthegreat:~#
> > I also used:
> > cryptsetup luksFormat --align-payload=8192
>
> It will not help if underlying partition is misaligned.
That's correct of course :)
Now I'm going to have to do some more reading to see whether I'm really
misaligned or not. I had done all the relevant reading on SSDs to make sure
I did use proper alignment.
I wonder why fdisk -H32 -S32 failed me.
> I think this one, try to increase it to 8192 or so...
>
> > nr_requests:128
Didn't help.
gandalfthegreat:/sys/block/sda/queue# echo 8192 > nr_requests
gandalfthegreat:/sys/block/sda/queue# hdparm -t -T /dev/mapper/cryptroot
/dev/mapper/cryptroot:
Timing cached reads: 14970 MB in 2.00 seconds = 7492.34 MB/sec
Timing buffered disk reads: 72 MB in 3.08 seconds = 23.35 MB/sec
gandalfthegreat:/sys/block/sda/queue#
Thanks for the other suggestions. Hopefully we'll nail this somehow :)
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/
next prev parent reply other threads:[~2012-07-23 17:51 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-22 19:07 [dm-crypt] aes-xts-plain with aes_x86_64 makes my SSD 5x slower than my encrypted HD Marc MERLIN
2012-07-22 19:47 ` Yves-Alexis Perez
2012-07-22 20:39 ` Marc MERLIN
2012-07-22 21:47 ` Arno Wagner
2012-07-23 6:07 ` Yves-Alexis Perez
2012-07-23 6:28 ` Marc MERLIN
2012-07-23 8:14 ` Arno Wagner
2012-07-23 10:46 ` Milan Broz
2012-07-23 11:09 ` Yves-Alexis Perez
2012-07-23 11:37 ` Milan Broz
2012-07-23 15:08 ` André Gall
2012-07-23 17:27 ` André Gall
2012-07-24 14:06 ` Heinz Diehl
2012-07-24 14:16 ` Milan Broz
2012-07-23 16:12 ` Marc MERLIN
2012-07-23 16:19 ` Yves-Alexis Perez
2012-07-23 17:54 ` Marc MERLIN
2012-07-23 19:26 ` Yves-Alexis Perez
2012-07-23 17:15 ` Milan Broz
2012-07-23 17:51 ` Marc MERLIN [this message]
2012-07-23 21:31 ` Milan Broz
2012-07-24 5:57 ` Marc MERLIN
2012-07-24 6:25 ` Heinz Diehl
2012-07-24 15:02 ` Marc MERLIN
2012-07-24 15:19 ` Milan Broz
2012-07-24 16:09 ` Marc MERLIN
2012-07-24 13:54 ` Milan Broz
[not found] ` <500E9099.8050501@redhat.com>
2012-07-24 14:27 ` Heinz Diehl
2012-07-24 14:58 ` Heinz Diehl
2012-07-24 15:38 ` Marc MERLIN
2012-07-24 16:48 ` Heinz Diehl
2012-07-24 6:11 ` Heinz Diehl
2012-07-22 21:55 ` Marc MERLIN
2012-07-22 20:22 ` Heinz Diehl
2012-08-12 12:49 ` Pasi Kärkkäinen
2012-08-16 7:43 ` Marc MERLIN
[not found] ` <502D1F96.3080905@andregall.de>
2012-08-16 17:57 ` Marc MERLIN
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120723175129.GA15867@merlins.org \
--to=marc@merlins.org \
--cc=corsac@debian.org \
--cc=dm-crypt@saout.de \
--cc=mbroz@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.