On 02/19/2017 01:46 PM, Gilad Ben-Yossef wrote: > Use of the synchronous digest API limits dm-verity to using pure > CPU based algorithm providers and rules out the use of off CPU > algorithm providers which are normally asynchronous by nature, > potentially freeing CPU cycles. > > This can reduce performance per Watt in situations such as during > boot time when a lot of concurrent file accesses are made to the > protected volume. > > Move DM_VERITY to the asynchronous hash API. > > Signed-off-by: Gilad Ben-Yossef <gilad@xxxxxxxxxxxxx> > CC: Eric Biggers <ebiggers3@xxxxxxxxx> > CC: Ondrej Mosnáček <omosnacek+linux-crypto@xxxxxxxxx> > CC: Milan Broz <gmazyland@xxxxxxxxx> > --- > > The patch was tested on an Armv7 based dual core Zynq ZC706 development > board with SHA256-asm, SHA256-neon synchronous providers with no visible > degradation of performance, with cryptd based asynchronous versions of the > same and with an off tree Arm CryptoCell asynchronous provider. > > Changes from v2: > > - Use completion to potentially wait also on crypto_ahash_init() as it > may finish asynchronously as well in some drivers, such as cryptd, as > discovered by Milan Broz. This version survived my simple veritysetup test (in cryptsetup package) with forced async path so I think it is ok for 4.12 queue... Thanks, Milan > - Use sg_init_one() where apropriate as pointed out by Milan Broz. > > Changes from v1: > > - Use a 0 mask to allocate crypto alg indicating we welcome async algo > providers, as suggested by Ondrej Mosnáček. > - Fix use of un-initialized completion when using async provider for IO > blocks hashing > - Pass flag indicating we are OK with crypto provider backlog > - Re-factor checking for need to wait into a common function >
