lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 14 Jul 2014 12:08:28 -0700
From:	Tim Chen <>
To:	Peter Zijlstra <>
Cc:	Herbert Xu <>,
	"H. Peter Anvin" <>,
	"David S.Miller" <>,
	Ingo Molnar <>,
	Chandramouli Narayanan <>,
	Vinodh Gopal <>,
	James Guilford <>,
	Wajdi Feghali <>,
	Jussi Kivilinna <>,,
Subject: Re: [PATCH v4 6/7] sched: add function nr_running_cpu to expose
 number of tasks running on cpu

On Mon, 2014-07-14 at 20:17 +0200, Peter Zijlstra wrote:
> On Mon, Jul 14, 2014 at 10:05:34AM -0700, Tim Chen wrote:
> > I was trying to explain why the algorithm is implemented this way
> > because of its batching nature.
> > 
> > There is a whole class of async algorithm that can provide
> > substantial speedup by doing batch processing and uses workqueue.
> > The multi-buffer sha1 version has 2.2x speedup over existing
> > AVX2 version, and can have even more speedup when AVX3 
> > comes round.  Workqueue is a natural way to implement 
> > this.  I don't think a throughput speedup of 2.2x is "crap".
> > 
> > We are not inventing anything new, but ask for a 
> > very simple helper function to know if there's something else
> > running on our cpu to help us make a better decision 
> > of whether we should flush the batched jobs immediately.
> > 
> > And also asynchronous crypto interface is already used substantially
> > in crypto and has a well established infrastructure.  
> The crap I was talking about is that there's a metric ton of 'async'
> interfaces all different.

Async interfaces when used appropriately, actually speed things up
substantially for crypto.  We actually have a case with
ecyrptfs not using the async crypto interface, causing cpu to stall
and slowing things down substantially with AES-NI.  And async interface
with workqueue speed things up (30% to 35% on encryption with SSD). 
> 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. 

> 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.

> it does not extend workqueues, 
Why do I need to extend workqueues if the existing ones already
meet my needs?

> it does not
> remove the btrfs nonsense, 
Not much I can do about btrfs as I don't understand the issues there.

> it adds yet anotehr thing.



To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists