On Mon, Feb 06, 2017 at 01:53:09PM +0100, Pavel Machek wrote:
> On Sat 2016-02-20 21:04:32, Pavel Machek wrote:
> > Hi!
> >
> > > > > > > I know it is normal to spawn 8 threads for every single function,
> > > > > > ...
> > > > > > > but 28 threads?
> > > > > > >
> > > > > > > root 974 0.0
On Mon, Feb 06, 2017 at 04:47:24PM -0900, Kent Overstreet wrote:
> On Mon, Feb 06, 2017 at 01:53:09PM +0100, Pavel Machek wrote:
> > Still there on v4.9, 36 threads on nokia n900 cellphone.
> >
> > So.. what needs to be done there?
> But, I just got an idea for how to handle this that might be ha
On Fri, Feb 03 2017 at 7:18pm -0500,
Linus Torvalds wrote:
> On Fri, Feb 3, 2017 at 11:11 AM, Mike Snitzer wrote:
> > are available in the git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git
> > dm-4.10-fixes
>
> Hmm.
>
>"fatal: Couldn't
Hi Eric,
On Mon, Jan 30, 2017 at 2:28 AM, Eric Biggers wrote:
...
> As for the patch, I haven't looked at it in detail, but I agree that if
> dm-verity is indeed operating on sufficiently large buffers in physically
> contiguous memory, then the ahash API would be better than the shash API.
>
On Sat 2016-02-20 21:04:32, Pavel Machek wrote:
> Hi!
>
> > > > > > I know it is normal to spawn 8 threads for every single function,
> > > > > ...
> > > > > > but 28 threads?
> > > > > >
> > > > > > root 974 0.0 0.0 0 0 ?S< Dec08 0:00
> > > > > > [bioset]
> > > > >
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
