From owner-freebsd-arch Mon Sep 11 17:18:29 2000 Delivered-To: freebsd-arch@freebsd.org Received: from magnesium.net (toxic.magnesium.net [207.154.84.15]) by hub.freebsd.org (Postfix) with SMTP id 5B3CE37B424 for ; Mon, 11 Sep 2000 17:18:27 -0700 (PDT) Received: (qmail 69229 invoked by uid 1142); 12 Sep 2000 00:18:26 -0000 Date: 11 Sep 2000 17:18:26 -0700 Date: Mon, 11 Sep 2000 17:18:19 -0700 From: Jason Evans To: Greg Lehey Cc: John Baldwin , Mark Murray , FreeBSD-arch@FreeBSD.org Subject: Re: cvs commit: src/sys/conf files src/sys/sys random.h src/sys/dev/randomdev hash.c hash.h harvest.c randomdev.c yarrow.c yarro Message-ID: <20000911171819.A31089@blitz.canonware.com> References: <20000911093457.H15703@wantadilla.lemis.com> <200009110111.SAA29487@pike.osd.bsdi.com> <20000912091705.O19431@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000912091705.O19431@wantadilla.lemis.com>; from grog@lemis.com on Tue, Sep 12, 2000 at 09:17:05AM +0930 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Sep 12, 2000 at 09:17:05AM +0930, Greg Lehey wrote: > [following up to -arch] > On Sunday, 10 September 2000 at 18:11:25 -0700, John Baldwin wrote: > > Greg Lehey wrote: > >> On Sunday, 10 September 2000 at 6:52:19 -0700, Mark Murray wrote: > >>> markm 2000/09/10 06:52:19 PDT > >>> > >>> Log: > >>> Large upgrade to the entropy device; mainly inspired by feedback > >>> from many folk. > >>> > >>> o The reseed process is now a kthread. With SMPng, kthreads are > >>> pre-emptive, so the annoying jerkiness of the mouse is gone. > >>> > >>> o The data structures are protected by mutexes now, not splfoo()/splx(). > >> > >> The last thing I heard was that we were getting worried about putting > >> in too many mutexes. How was this resolved? > > > > IIRC, Mark's code doesn't tsleep() with a mutex, which was one of > > the problems that the malloc() mutex patch had. Although, in my > > opinion, we'd probably be better off starting with large subsystem > > locks as the first step of the lock pushdown, and then successively > > push down the locks within each subsystem and sub-subsystem. I > > think trying to add a bunch of small locks in the beginning will > > just give us massive amounts of headaches. Mark's changes to randomdev are very straight-forward, and they use a mutex exactly as a mutex should be used (though a condition variable will help make things even cleaner, once they're available). A general discussion of high level locking strategy is in order, but in my opinion, Mark's code is not an appropriate harbinger, since there's absolutely nothing wrong with the approach he took, regardless of the results of high level discussion. The issue we need to decide on is how to avoid bad interactions (read deadlock/livelock) between mutex hierarchies, but the randomdev mutex basically stands alone, so isn't subject to those discussions. Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message