From owner-freebsd-current@FreeBSD.ORG Thu Aug 5 04:33:59 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DBEC516A4CE; Thu, 5 Aug 2004 04:33:58 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 467A143D2F; Thu, 5 Aug 2004 04:33:58 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.155] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BsZwz-0006J6-00; Thu, 05 Aug 2004 06:33:57 +0200 Received: from [217.83.3.226] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1BsZwy-0007z2-00; Thu, 05 Aug 2004 06:33:57 +0200 From: Max Laier To: freebsd-current@freebsd.org Date: Thu, 5 Aug 2004 06:31:51 +0200 User-Agent: KMail/1.6.2 References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_AhbEBoH+KLmzG/t"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408050632.00671.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 cc: markm@FreeBSD.org cc: Robert Watson Subject: Re: So much entropy it's coming out of our ears? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2004 04:33:59 -0000 --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--