linux-kernel - Re: [PATCH 0/2] Introduce the request handling for dm-crypt

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5644AFA2.6040201@kernel.dk>
Date:	Thu, 12 Nov 2015 08:26:26 -0700
From:	Jens Axboe <axboe@...nel.dk>
To:	Mark Brown <broonie@...nel.org>,
	Baolin Wang <baolin.wang@...aro.org>
Cc:	Mike Snitzer <snitzer@...hat.com>,
	Alasdair G Kergon <agk@...hat.com>, dm-devel@...hat.com,
	neilb@...e.com, linux-raid@...r.kernel.org, jack@...e.cz,
	Arnd Bergmann <arnd@...db.de>,
	LKML <linux-kernel@...r.kernel.org>, keith.busch@...el.com,
	jmoyer@...hat.com, tj@...nel.org, bart.vanassche@...disk.com,
	"Garg, Dinesh" <dineshg@...cinc.com>
Subject: Re: [PATCH 0/2] Introduce the request handling for dm-crypt

On 11/12/2015 03:04 AM, Mark Brown wrote:
> On Thu, Nov 12, 2015 at 04:20:41PM +0800, Baolin Wang wrote:
>
>> 3. perforamence data
>> It is just a simple dd test result, and will provide the formal report
>> in future. But from the simple test, we can see the improvement.
>
> It's probably also worth pointing out that Qualcomm have been shipping
> an out of tree implementation of this as a separate module in their BSP
> (originally written by Danesh Garg who's on this thread):
>
>     https://android.googlesource.com/kernel/msm/+/android-msm-dory-3.10-kitkat-wear/drivers/md/dm-req-crypt.c
>
> Android now wants to encrypt phones and tablets by default and have been
> seeing substantial performance hits as a result, we can try to get
> people to share performance data from productionish systems but it might
> be difficult.

Well, shame on them for developing out-of-tree, looks like they are 
reaping all the benefits of that.

Guys, we need some numbers, enough with the hand waving. There's no 
point discussing this further until we know how much of a difference it 
makes to handle X MB chunks instead of Y MB chunks. As was previously 
stated, unless there's a _substantial_ performance benefit, this 
patchset isn't going anywhere.

If there is a huge benefit, we can look into ways of making it actually 
work. That may not even be a request interface, it could just be proper 
utilization of plugging for in-dm bio merging.

-- 
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/