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

[Peter Zijlstra <peterz@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 1302 bytes --]

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.
> http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/fast-multi-buffer-ipsec-implementations-ia-processors-paper.pdf 

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 #2: Type: application/pgp-signature, Size: 836 bytes --]