locks and kernel randomness...

[K. Macy]

> 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
cycles doing a SHA256 because it's "The Right Thing"(tm) when their
use case only requires a fletcher2.

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.