[lkml]   [2018]   [Mar]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 2/2] md: dm-verity: allow parallel processing of bio blocks
On Tue, Mar 27 2018 at  4:55am -0400, <> wrote:

> Hi Mike
> I need to rewrite these patches according to issues you and Eric Biggers mentioned.
> please drop this v1 patch.

They've been dropped. BUT please do note that the patches I pushed to
linux-dm.git were rebased ontop of the 'check_at_most_once' patch.

I never did get an answer about how the sg array is free'd in certain
error paths (see "FIXME:" in the 2nd patch).

Also, I fixed some issues I saw in error paths, and lots of formatting.

I'll be pretty frustrated if you submit v2 that is blind to the kinds of
changes I made.

I'll send you a private copy of the patches just so you have them for
your reference.


> -----Original Message-----
> From: Mike Snitzer <>
> Sent: Tuesday, 27 March 2018 4:07
> To: Yael Chemla <>
> Cc: Alasdair Kergon <>;;;; Yael Chemla <>
> Subject: Re: [PATCH 2/2] md: dm-verity: allow parallel processing of bio blocks
> On Sun, Mar 25 2018 at 2:41pm -0400,
> Yael Chemla <> wrote:
> > Allow parallel processing of bio blocks by moving to async.
> > completion handling. This allows for better resource utilization of
> > both HW and software based hash tfm and therefore better performance
> > in many cases, depending on the specific tfm in use.
> >
> > Tested on ARM32 (zynq board) and ARM64 (Juno board).
> > Time of cat command was measured on a filesystem with various file sizes.
> > 12% performance improvement when HW based hash was used (ccree driver).
> > SW based hash showed less than 1% improvement.
> > CPU utilization when HW based hash was used presented 10% less
> > context switch, 4% less cycles and 7% less instructions. No
> > difference in CPU utilization noticed with SW based hash.
> >
> > Signed-off-by: Yael Chemla <>
> This one had various issues. I've fixed most of what I saw and staged in linux-next (purely for build test coverage purposes). I may drop this patch if others disagree with it (or my sg deallocation in the error path question isn't answered).
> I've staged the changes here (and in linux-next via 'for-next'):
> I switched all the new GFP_KERNEL uses to GFP_NOIO. The fact that you're doing allocations at all (per IO) is bad enough. Using GFP_KERNEL is a serious liability (risk of deadlock if dm-verity were to be used for something like.. swap.. weird setup but possible).
> But the gfp flags aside, the need for additional memory and the expectation of scalable async parallel IO is potentially at odds with changes like this (that I just staged, and had to rebase your 2 patches ontop of):
> So I'm particulalry interested to hear from google folks to understand if they are OK with your proposed verity async crypto API use.
> Mike

 \ /
  Last update: 2018-03-27 15:20    [W:0.077 / U:0.580 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site