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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 13 Nov 2015 10:07:25 +0800
From:	Baolin Wang <baolin.wang@...aro.org>
To:	Jens Axboe <axboe@...nel.dk>
Cc:	Mark Brown <broonie@...nel.org>, Mike Snitzer <snitzer@...hat.com>,
	Alasdair G Kergon <agk@...hat.com>, dm-devel@...hat.com,
	neilb@...e.com, linux-raid@...r.kernel.org,
	Jan Kara <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 12 November 2015 at 23:26, Jens Axboe <axboe@...nel.dk> wrote:
> 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.

That's fair enough and we will provide the performance data to measure
the patchset.

>
> 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.

Make sense. Thanks.

>
> --
> Jens Axboe
>



-- 
Baolin.wang
Best Regards
--
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/

Powered by blists - more mailing lists