Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755191AbbLBT5E (ORCPT ); Wed, 2 Dec 2015 14:57:04 -0500 Received: from mx1.redhat.com ([209.132.183.28]:43224 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751614AbbLBT5B (ORCPT ); Wed, 2 Dec 2015 14:57:01 -0500 Date: Wed, 2 Dec 2015 19:56:57 +0000 From: Alasdair G Kergon To: Baolin Wang Cc: Mark Brown , Jens Axboe , keith.busch@intel.com, Jan Kara , Arnd Bergmann , Mike Snitzer , neilb@suse.com, LKML , linux-raid@vger.kernel.org, dm-devel@redhat.com, "Garg, Dinesh" , tj@kernel.org, bart.vanassche@sandisk.com, jmoyer@redhat.com, Alasdair G Kergon , Mikulas Patocka Subject: Re: [dm-devel] [PATCH 0/2] Introduce the request handling for dm-crypt Message-ID: <20151202195657.GB11127@agk-dp.fab.redhat.com> Mail-Followup-To: Baolin Wang , Mark Brown , Jens Axboe , keith.busch@intel.com, Jan Kara , Arnd Bergmann , Mike Snitzer , neilb@suse.com, LKML , linux-raid@vger.kernel.org, dm-devel@redhat.com, "Garg, Dinesh" , tj@kernel.org, bart.vanassche@sandisk.com, jmoyer@redhat.com, Alasdair G Kergon , Mikulas Patocka References: <20151111181813.GD12236@redhat.com> <20151112100422.GM12392@sirena.org.uk> <5644AFA2.6040201@kernel.dk> <20151113115144.GR12392@sirena.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Red Hat UK Ltd. Registered in England and Wales, number 03798903. Registered Office: 64 Baker Street, 4th floor, London, W1U 7DF. User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1289 Lines: 29 On Wed, Dec 02, 2015 at 08:46:54PM +0800, Baolin Wang wrote: > These are the benchmarks for request based dm-crypt. Please check it. Now please put request-based dm-crypt completely to one side and focus just on the existing bio-based code. Why is it slower and what can be adjusted to improve this? People aren't going to take a request-based solution seriously until you can explain in full detail *why* bio-based is slower AND why it's impossible to improve its performance. > For request based things, some sequential bios/requests can merged > into one request to expand the IO size to be a big block handled by > hardware engine at one time. Bio-based also merges I/O so that does not provide justification. Investigate in much more detail the actual merging and scheduling involved in the cases you need to optimise. See if blktrace gives you any clues, or add your own instrumentation. You could even look at some of the patches we've had in the list archives for optimising bio-based crypt in different situations. Alasdair -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/