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 JOYHzILE19R2 for ; Sun, 22 Jul 2012 22:59:32 +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 ; Sun, 22 Jul 2012 22:59:32 +0200 (CEST) Date: Sun, 22 Jul 2012 13:39:29 -0700 From: Marc MERLIN Message-ID: <20120722203929.GB3925@merlins.org> References: <20120722190757.GB10089@merlins.org> <20120722202213.GA7306@fancy-poultry.org> <20120722190757.GB10089@merlins.org> <1342986452.26887.3.camel@scapa> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120722202213.GA7306@fancy-poultry.org> <1342986452.26887.3.camel@scapa> 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: Yves-Alexis Perez , dm-crypt@saout.de, htd@fancy-poultry.org 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: > > root@scapa:~# hdparm -t /dev/sda /dev/mapper/scapa_crypt > > /dev/sda: > Timing buffered disk reads: 690 MB in 3.01 seconds = 229.47 MB/sec > /dev/mapper/scapa_crypt: > Timing buffered disk reads: 590 MB in 3.00 seconds = 196.43 MB/sec Right, that's more what I would expect. On Sun, Jul 22, 2012 at 10:22:13PM +0200, Heinz Diehl wrote: > I don't know why reading speed is that slow in your case, especially > as you are using AES-NI, which should give you the highest speed > available. Maybe others here on the list have a suggestion. Probably, > you should provide some more information. I'm happy to if you tell me what else I can give. Note how my test showed that I had the same aes-xts-plain on the hard drive in the same laptop, and that one runs at 100MB/s, which is pretty much its native speed. Just to make sure that I'm not CPU limited, I tried gandalfthegreat:~# dd if=/dev/sda4 of=/dev/null bs=1M count=1024 1073741824 bytes (1.1 GB) copied, 2.23959 s, 479 MB/s 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 > Otherwise, on the newer Intel i3/i5/i7, twofish-3way is faster than > AES. You could try to re-format your drive with twofish-xts-plain64 > and adding twofish_common, twofish_x86_64 and twofish_x86_64_3way to > your initram (as long as your kernel is built with these enabled). Thanks for the hint. Since it's a lenovo T530 with a recent CPU, I tried it: gandalfthegreat:~# cryptsetup -c twofish-xts-plain64 -s 256 luksFormat /dev/sda4 Result is the same: gandalfthegreat:~# hdparm -tT /dev/mapper/ssdcrypt /dev/mapper/ssdcrypt: Timing cached reads: 16614 MB in 2.00 seconds = 8317.50 MB/sec Timing buffered disk reads: 68 MB in 3.08 seconds = 22.09 MB/sec Grumble. 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. Thanks for the answers, 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/