Date: Thu, 23 Jul 2015 22:32:17 +0100 From: Mark R V Murray <markm@FreeBSD.org> To: Scott Long <scott4long@yahoo.com> Cc: src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: 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... Message-ID: <5E95F097-2C85-48C2-8E34-8EA46EDBE6A3@FreeBSD.org> In-Reply-To: <F54A96A8-D9AD-409A-814F-538B6AD3CD50@yahoo.com> References: <201506301700.t5UH0jPq001498@svn.freebsd.org> <alpine.BSF.2.20.1507221138360.1071@desktop> <FFAED695-145A-45F5-988D-B843EF5F544B@FreeBSD.org> <alpine.BSF.2.20.1507221249120.1071@desktop> <FFFB06D7-164B-40B3-AFC3-A6630BCF074E@bsdimp.com> <E20B169F-4C8A-4D11-9853-5C2EFC116450@FreeBSD.org> <F54A96A8-D9AD-409A-814F-538B6AD3CD50@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 23 Jul 2015, at 14:45, Scott Long <scott4long@yahoo.com> wrote: >=20 >> OK - I=E2=80=99m sold! I=E2=80=99ll make a kernel option defaulting = to off. :-) >>=20 >>=20 >=20 > Hi Mark, >=20 > 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=E2=80=99d known this earlier, or, if I *was* told, I = wish I=E2=80=99d 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=E2=80=99m 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=E2=80=99= s enabled by default, benchmarks will be impacted and people will react. = That=E2=80=99ll be a huge step backwards for FreeBSD. Understood, and thanks. If you have any suitable benchmark code that I = could have, please, I=E2=80=99d be very grateful. > I also strongly agree with Jeff=E2=80=99s point on the questionable = nature of this kind of fast-and-monotonic entropy collection, and Warner = and Kip=E2=80=99s point on the finite number of clock cycles available = for doing 100Gb networking. If really high quality entropy is desired, = won=E2=80=99t most serious people use a hardware source instead of a = software source? Not that I think that software entropy is useless, but = it=E2=80=99s 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=E2=80=99t 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=E2=80=99s so disabling some sources would be a = reasonable idea. I trust this direction will work better for more folks? M --=20 Mark R V Murray
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5E95F097-2C85-48C2-8E34-8EA46EDBE6A3>