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 cvo-qQZ5dC33 for ; Mon, 23 Jul 2012 13:37:47 +0200 (CEST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mail.saout.de (Postfix) with ESMTP for ; Mon, 23 Jul 2012 13:37:47 +0200 (CEST) Message-ID: <500D3776.2000307@redhat.com> Date: Mon, 23 Jul 2012 13:37:26 +0200 From: Milan Broz MIME-Version: 1.0 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> <20120723062850.GA6931@merlins.org> <20120723081407.GA872@tansi.org> <500D2B8E.3000908@redhat.com> <1343041780.26887.19.camel@scapa> In-Reply-To: <1343041780.26887.19.camel@scapa> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 Cc: dm-crypt@saout.de, Marc MERLIN On 07/23/2012 01:09 PM, Yves-Alexis Perez wrote: > On lun., 2012-07-23 at 12:46 +0200, Milan Broz wrote: >> So no wonder that you get slow operation - in dd/hdparm usually only >> one cpu is processing the request. If CPU is fast enough, no problem. >> If not you will see slowdown. AES-NI will speed up this on that cpu >> core, >> but will not help run request in parallel on multi-core systems. > > Then I should see slow operations too, since I'm doing exactly the same > test. My guess is that is a kernel issue somewhere, but maybe we should > try a common ground (say, a grml live or some fedora live) and report > back? Well, yes. I explained dmcrypt part, there can be other problem. E.g. alignment (bit it _seems_ correct from mails). Reading again, 23MB/s is really slow, so yes there must be something else. Common distro env is nice but be sure you have proper crypto modules available. Also do not use Fedora rawhide, it has kernel compiled with debug tools not usable for testing. You can try start with this: 1) (this should be not problem but better check it) Check alignment of partitions. Is it aligned to SSD page size? (Aligning to 1MiB is always correct ;-) Paste fdisk -l -u /dev/sda 2) try to switch io scheduler to "noop" or "deadline" (paste lsblk -t) You can do it online for sda (again, check with lsblk -t): echo "noop">/sys/block/sda/queue/scheduler Also you can try to increase queue size. (Hard core version is to run blktrace and check if request are not split unnecessarily :) 3) Let's test cipher_null (no encryption just fake-copy) (you need cryptsetup 1.4.3 for this test). create test LUKS device with null cipher: cryptsetup luksFormat -c null Repeat tests now - is the problem the same? (please send output). (For dmcrypt device speed should be only slighly slower.) please note: cipher null means no encryption, just use dmcrypt layer, so do not use for valid data :-) 4) which aes module are you using? check lsmod, check /proc/crypto you should use either aes-ni or optimized modules (x86_64 etc) Milan p.s. sorry for removing cc on first reply, my mistake.