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 O-UrMPEdbPT4 for ; Mon, 23 Jul 2012 08:29:01 +0200 (CEST) Received: from mail1.merlins.org (magic.merlins.org [209.81.13.136]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Mon, 23 Jul 2012 08:29:01 +0200 (CEST) Date: Sun, 22 Jul 2012 23:28:51 -0700 From: Marc MERLIN Message-ID: <20120723062850.GA6931@merlins.org> References: <20120722190757.GB10089@merlins.org> <20120722202213.GA7306@fancy-poultry.org> <20120722190757.GB10089@merlins.org> <1342986452.26887.3.camel@scapa> <20120722203929.GB3925@merlins.org> <20120722214757.GA16793@tansi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120722214757.GA16793@tansi.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, Arno Wagner On Sun, Jul 22, 2012 at 11:47:57PM +0200, Arno Wagner wrote: > 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 was worth a shot, thanks for the suggestion. gandalfthegreat:~# lsmod | grep aes aes_x86_64 16796 34 gandalfthegreat:~# hdparm -t -T /dev/mapper/cryptroot /dev/mapper/cryptroot: Timing cached reads: 15802 MB in 2.00 seconds = 7909.98 MB/sec Timing buffered disk reads: 68 MB in 3.04 seconds = 22.39 MB/sec gandalfthegreat:~# Unfortunately, speed is exactly the same. with aes_x86_64: gandalfthegreat:/var/local/VirtualBox VMs/w2k_virtual# dd if=test of=/dev/null 4192640+0 records in 4192640+0 records out 2146631680 bytes (2.1 GB) copied, 12.4848 s, 172 MB/s I then rebooted with aesni_intel and got this: gandalfthegreat:/var/local/VirtualBox VMs/w2k_virtual# dd if=test of=/dev/null 4192640+0 records in 4192640+0 records out 2146631680 bytes (2.1 GB) copied, 8.42506 s, 255 MB/s So those speeds are expected/believable, but I still don't know why hdparm is so slow on /dev/mapper/cryptroot. Mmmh.... 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/