All of lore.kernel.org
 help / color / mirror / Atom feed
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 

  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.