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