From: Arno Wagner <arno@wagner.name>
To: 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: Sun, 22 Jul 2012 23:47:57 +0200 [thread overview]
Message-ID: <20120722214757.GA16793@tansi.org> (raw)
In-Reply-To: <20120722203929.GB3925@merlins.org>
On Sun, Jul 22, 2012 at 01:39:29PM -0700, Marc MERLIN wrote:
> On Sun, Jul 22, 2012 at 09:47:32PM +0200, Yves-Alexis Perez wrote:
> > > Any suggestions would be appreciated.
> >
> > I'm using Debian sid (so still at 3.2 kernel), currently using a 256G
> > Samsung SSD. What I get is:
SID? That would be "unstable", whit possible assorted problems.
[...]
> gandalfthegreat:~# dd if=/dev/mapper/ssdcrypt of=/dev/null bs=1M count=1024
> 1073741824 bytes (1.1 GB) copied, 44.3302 s, 24.2 MB/s
>
> atop shows dd isn't really pegging a single core:
> THR SYSCPU USRCPU RDDSK WRDSK ST EXC S CPUNR CPU CMD
> 1 0.60s 0.01s 226.2M 0K -- - D 3 6% dd
It would not, as AES-NI (AFAIK) does need very little CPU
assistance. AES-NI may be the problem though. Can you try with
the normal AES module? I think unloading the AES-NI module
may be enough for that, but I am not sure.
Maybe AES-NI needs very long for something it needs to do each
sector. Google("aes-ni slow") found at least some indications that
aes-ni may still have problems.
[...]
> It shouldn't be a hardware problem since I do see 400MB/s before encryption.
>
> I'm a bit lost here. I'll try other kernels just in case, but that shouldn't
> make a difference.
It could. I remember that some time ago, quite a few people
had issues with slow crypto due to some problems in the
device-mapper layers. You might have hit that.
Here is one benchmark from me, 1GB luks-file via /dev/loop,
residing on a 3-way RAID1 with 2 HDDs as write-mostly
and one older SSD. Kernel is 3.3.8, self-compiled on top of
Debian squeeze, pure software AES on AMD quad-core. (Yes,
I know this is complicated, but apparently works well, see
below ;-)
/dev/mapper/x1:
Timing buffered disk reads: 612 MB in 3.00 seconds = 203.80 MB/sec
And the raw SSD:
/dev/sdd:
Timing buffered disk reads: 618 MB in 3.01 seconds = 205.56 MB/sec
Arno
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name
GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
----
One of the painful things about our time is that those who feel certainty
are stupid, and those with any imagination and understanding are filled
with doubt and indecision. -- Bertrand Russell
next prev parent reply other threads:[~2012-07-22 21:47 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 [this message]
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
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=20120722214757.GA16793@tansi.org \
--to=arno@wagner.name \
--cc=dm-crypt@saout.de \
/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.