Re: [PATCH v4 6/7] sched: add function nr_running_cpu to expose number of tasks running on cpu

From: Peter Zijlstra
Date: Mon Jul 14 2014 - 15:15:26 EST

On Mon, Jul 14, 2014 at 12:08:28PM -0700, Tim Chen wrote:
> On Mon, 2014-07-14 at 20:17 +0200, Peter Zijlstra wrote:

> > Your multi-buffer thing isn't generic either, it seems lmiited to sha1.
> We actually have many other multi-buffer crypto algorithms already
> published for encryption and other IPSec usages. So
> multi-buffer algorithm is not just limited to SHA1.
> We hope to port those to the kernel crypto library eventually.

That's all nice and such; but the code as I've seen in these patches is
very much sha1 specific. The mb part isn't separated out.

> > It does not reuse padata,
> padata tries to speed things up by parallelizing jobs to *multiple*
> cpus. Whereas multi-buffer tries to speed things up by speeding things
> up by using multiple data lanes in SIMD register in a *single* cpu.
> These two usages are complementary but not the same.

And if its single cpu, wth do you need that nr_running thing for another
cpu for?

Also, this difference wasn't clear to me.

I still loathe all the async work, because it makes a mockery of
accounting etc.. but that's a story for another day I suppose :-(

Attachment: pgplqq3axOtU0.pgp
Description: PGP signature