svn commit: r284959 - in head: . share/man/man4 share/man/man9 sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe sys/dev/syscons sys/dev/ubsec sys/dev/virtio/random sy...

[Mark R V Murray]

> On 23 Jul 2015, at 14:45, Scott Long <scott4long at yahoo.com> wrote:
> 
>> OK - I’m sold! I’ll make a kernel option defaulting to off. :-)
>> 
>> 
> 
> Hi Mark,
> 
> Thanks for making this concession.  I wanted to add a bit of historical perspective.  When Yarrow was introduced in the previous decade, it was initially wired into nearly all interrupt sources.  It turned out to be so expensive to those sources, especially for high-speed sources at the time like network and caching RAID drivers, that we then spent months disabling it from those sources.  In the end, a lot of code thrash happened and the effectiveness of Yarrow was questionable.

OK. OUCH. I wish I’d known this earlier, or, if I *was* told, I wish I’d paid a bit more attention. :-]

In a nod towards efficiency, I have supplied graded (*_fast(), *_queue(), *_direct()) harvesting types, but it would appear that these are insufficient for your purposes. No problem, I’m glad we could come to another compromise!

> Fast forward to now with your recent work.  If UMA becomes expensive for high-speed use, everyone will go back to developing private per-driver and per-subsystem allocators to avoid it.  This will happen whether or not the UMA collector is controllable at run-time; if it’s enabled by default, benchmarks will be impacted and people will react.  That’ll be a huge step backwards for FreeBSD.

Understood, and thanks. If you have any suitable benchmark code that I could have, please, I’d be very grateful.

> I also strongly agree with Jeff’s point on the questionable nature of this kind of fast-and-monotonic entropy collection, and Warner and Kip’s point on the finite number of clock cycles available for doing 100Gb networking.  If really high quality entropy is desired, won’t most serious people use a hardware source instead of a software source?  Not that I think that software entropy is useless, but it’s a question of how much effort and tradeoffs are put into it for what result.  An academically beautiful entropy system that hamstrings the OS from doing other essential things isn’t all that interesting, IMO.

I am kinda hoping to be useful for everybody without being a nuisance. Fortuna (and Yarrow) work best with diverse sources of entropy, and we have declared our distrust in single sources (thanks Snowden!). Thus it is good to mix as much as possible. Now your requirements may not be as strong as the next fellow’s so disabling some sources would be a reasonable idea.

I trust this direction will work better for more folks?

M
-- 
Mark R V Murray