locks and kernel randomness...

[John-Mark Gurney]

K. Macy wrote this message on Tue, Feb 24, 2015 at 15:33 -0800:
> > If someone does find a performance issue w/ my patch, I WILL work with
> > them on a solution, but I will not work w/ people who make unfounded
> > claims about the impact of this work...
> >
> 
> <shrug> ... The concerns may be exaggerated, but they aren't
> unfounded. Not quite the same thing, but no one wants to spend the

Till someone shows me code in the kernel tree where this is even close
to a performance problem, it is unfounded...  I've asked, and no one
has 

> cycles doing a SHA256 because it's "The Right Thing"(tm) when their
> use case only requires a fletcher2.

Depends upon what you're doing.. I haven't proposed changing ZFS's
default to sha256, so stop w/ the false equivalences...

> If it doesn't already exist, it might also be worth looking in to a
> more scalable CSPRNG implementation not requiring locking in the
> common case. For example, each core is seeded separately periodically
> so that has a private pool that is protected by a critical section.
> The private pool would be regularly refreshed by cpu-local callout.
> Thus, a lock would only be acquired if the local entropy were
> depleted.

I'm not discussing this until you read and reply to my original email,
since it's clear that my original email's contents has been ignored in
this thread...

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."