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 5tymP7FY3B64 for ; Sun, 10 Mar 2013 16:06:48 +0100 (CET) Received: from mail-bk0-x234.google.com (mail-bk0-x234.google.com [IPv6:2a00:1450:4008:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Sun, 10 Mar 2013 16:06:48 +0100 (CET) Received: by mail-bk0-f52.google.com with SMTP id jk13so1304267bkc.25 for ; Sun, 10 Mar 2013 08:06:48 -0700 (PDT) Message-ID: <513CA157.3000009@gmail.com> Date: Sun, 10 Mar 2013 16:05:59 +0100 From: Milan Broz MIME-Version: 1.0 References: <20130122054223.GA25850@tansi.org> <50FE3EAF.3070206@gmail.com> <50FEB647.8060005@gmail.com> <51066847.90305@gmail.com> <20130305125304.3a8e37d5@midna.rag.lan> In-Reply-To: <20130305125304.3a8e37d5@midna.rag.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] Encrypting with larger packet size (+some experimental patch) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Stapelberg Cc: dm-crypt@saout.de On 5.3.2013 12:53, Michael Stapelberg wrote: > dd if=/dev/zero of=/dev/mapper/sda2_crypt bs=1M count=1024 oflag=direct > 1073741824 bytes (1.1 GB) copied, 50.5507 s, 21.2 MB/s > > This is just to let you know where I am coming from :). ... > dd if=/dev/zero of=/dev/mapper/sda2_crypt bs=1M count=1024 oflag=direct > 1073741824 bytes (1.1 GB) copied, 26.4864 s, 40.5 MB/s So 2 * performance increase? I would expect even more... (Maybe compare it with new cryptsetup benchmark - in fact it uses much larger block and it should measure almost real throughput or crypto engine.) > I would appreciate it very much if you could implement the FIXME and > commit that patch to dmcrypt. As I said, it is on my TODO list, kernel support is only one part of the problem. ANyway, I added http://code.google.com/p/cryptsetup/issues/detail?id=150 to track it. > BTW, when using a block_size of more than 4096 (e.g. 8192), > I get a kernel oops: > > [ 36.601704] device-mapper: ioctl: 4.23.1-ioctl (2012-12-18) initialised: dm-devel@redhat.com > [ 36.658525] bio: create slab at 1 > [ 36.672332] Unable to handle kernel NULL pointer dereference at virtual address 00000000 > [ 37.026882] [] (create_empty_buffers+0x24/0x11c) from [] (create_page_buffers+0x34/0x4c) > [ 37.036764] [] (create_page_buffers+0x34/0x4c) from [] (block_read_full_page+0x24/0x358) > [ 37.046646] [] (block_read_full_page+0x24/0x358) from [] (__do_page_cache_readahead+0x194/0x1ec) > [ 37.057230] [] (__do_page_cache_readahead+0x194/0x1ec) from [] (force_page_cache_readahead+0x6c/0xa4) > [ 37.068240] [] (force_page_cache_readahead+0x6c/0xa4) from [] (generic_file_aio_read+0x290/0x6dc) > [ 37.078906] [] (generic_file_aio_read+0x290/0x6dc) from [] (do_sync_read+0x90/0xcc) > [ 37.088348] [] (do_sync_read+0x90/0xcc) from [] (vfs_read+0xa4/0x17c) > [ 37.096569] [] (vfs_read+0xa4/0x17c) from [] (sys_read+0x38/0x64) > [ 37.104447] [] (sys_read+0x38/0x64) from [] (ret_fast_syscall+0x0/0x2c) > [ 37.112924] Code: e1a05000 e1a03000 ea000000 e1a03001 (e5932000) > [ 37.119055] ---[ end trace c844ca55a4ae58f6 ]--- This looks like crash in different layer, IMHO this should happen even with other devices (try dm-linear). If it is reproducible, perhaps report it to LKML. Thanks, Milan