Date: Thu, 5 Aug 2004 06:31:51 +0200 From: Max Laier <max@love2party.net> To: freebsd-current@freebsd.org Cc: Robert Watson <rwatson@FreeBSD.org> Subject: Re: So much entropy it's coming out of our ears? Message-ID: <200408050632.00671.max@love2party.net> In-Reply-To: <Pine.NEB.3.96L.1040804234812.19039J-100000@fledge.watson.org> References: <Pine.NEB.3.96L.1040804234812.19039J-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--Boundary-02=_AhbEBoH+KLmzG/t Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 05 August 2004 05:56, Robert Watson wrote: > As you know, I'm currently profiling and tracing our inbound and outbound > network stacks, and I've already bothered you with an e-mail about lock > coalescing and avoiding lock thrashing in the Yarrow thread. This is more > of the same sort of thing, and is about per-packet processing costs. > > I've observed in tracing that we grab and release two entropy related spin > mutexes for every ethernet packet processed. We do this in the ithread > before the netisr runs, and it directly introduces latency (and cost) in > the network path. Here's a sample trace fragment from receiving an > ethernet packet: > > 12024 0 1280 ithread_schedule: setrunqueue 27 > 12025 0 1480 UNLOCK (spin mutex) sched lock r =3D 0 at > ../../../kern/kern_intr.c:414 12026 0 1048 LOCK (spin mutex) > entropy harvest r =3D 0 at ../../../dev/random/randomdev_soft.c:300 12027= 0 > 788 LOCK (spin mutex) entropy harvest buffers r =3D 0 at > ../../../dev/random/randomdev_soft.c:309 12028 0 856 UNLOCK > (spin mutex) entropy harvest buffers r =3D 0 at > ../../../dev/random/randomdev_soft.c:317 12029 0 616 UNLOCK > (spin mutex) entropy harvest r =3D 0 at > ../../../dev/random/randomdev_soft.c:338 > > On inspecting random_harvest_internal(), it seems to be the case upfront > that we can do an unlocked read of harvestfifo[origin].count to compare > with RANDOM_FIFO_MAX and avoid any locks in the event that the event fifo > is full. Obviously, you'd need to retest after acquiring the locks in the > event there would appear to be room, but assuming that the fifo will often > be full under load, this would save a useful amount of cost. I haven't > attempted to measure how often the fifo fills, however, so can't currently > reason about whether that will save work in the common case. > > Another observation is that we seem to be doing a lot of entropy > gathering. That is to say -- a lot. On a busy system, I have to wonder > whether we're not paying a high cost to gather more entropy than we really > need. I'm not familiar with the Yarrow implementation nor harvesting > bits, but I'd pose this question to you: right now, we appear to pay four > mutex operations per packet if the fifo isn't full. Can we rate limit > entropy gathering in entropy-rich systems to avoid doing so much work? If > we're processing 25,000 or 100,000 packets a second, that's a lot of goup > passing through Yarrow. Is it possible to do lockless rate limiting so > that we gather it only once every few seconds? This might make a big > aggregate difference when processing ethernet packets at a high rate, such > as in bridging/forwarding scenarios, etc. Stupid question: Why do we try to make sure that *entropy* is passed reliab= le?=20 i.e. wouldn't it be enough to store it (unlocked) "somewhere" inside a circ= le=20 buffer and read from it (unlocked) to turn it into randomness. The potentia= l=20 race just gives some extra entropy. But as I started, might be a stupid question. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --Boundary-02=_AhbEBoH+KLmzG/t Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBBEbhAXyyEoT62BG0RAly8AJ4nWEQp3kfiCCgrAFc3BWdh4Ed0bwCdEq4o Xh/Ys+gFUtgxP/ro1yfVP5M= =ePOm -----END PGP SIGNATURE----- --Boundary-02=_AhbEBoH+KLmzG/t--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200408050632.00671.max>