locks and kernel randomness...

[Alfred Perlstein]

On 2/24/15 7:23 PM, John-Mark Gurney wrote:
> 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...
>
What is final proposal?  More spinlocks?  That is not a good idea.

Doing a single buildworld is not enough.  Ask netflix or someone with a 
real load of 1000s of threads/processing to do testing for you if you 
truly want to touch scheduler.

-Alfred