From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTL1IdbagauV for ; Sun, 22 Jul 2012 23:47:58 +0200 (CEST) Received: from v4.tansi.org (ns.km33513-03.keymachine.de [87.118.94.3]) by mail.saout.de (Postfix) with ESMTP for ; Sun, 22 Jul 2012 23:47:58 +0200 (CEST) Received: from gatewagner.dyndns.org (84-72-142-78.dclient.hispeed.ch [84.72.142.78]) by v4.tansi.org (Postfix) with ESMTPA id 5ECD3205937 for ; Sun, 22 Jul 2012 23:47:58 +0200 (CEST) Date: Sun, 22 Jul 2012 23:47:57 +0200 From: Arno Wagner Message-ID: <20120722214757.GA16793@tansi.org> References: <20120722190757.GB10089@merlins.org> <20120722202213.GA7306@fancy-poultry.org> <20120722190757.GB10089@merlins.org> <1342986452.26887.3.camel@scapa> <20120722203929.GB3925@merlins.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120722203929.GB3925@merlins.org> Subject: Re: [dm-crypt] aes-xts-plain with aes_x86_64 makes my SSD 5x slower than my encrypted HD List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de 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