Date: Mon, 11 Sep 2000 17:18:19 -0700 From: Jason Evans <jasone@canonware.com> To: Greg Lehey <grog@lemis.com> Cc: John Baldwin <jhb@pike.osd.bsdi.com>, Mark Murray <markm@FreeBSD.org>, 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> In-Reply-To: <20000912091705.O19431@wantadilla.lemis.com>; from grog@lemis.com on Tue, Sep 12, 2000 at 09:17:05AM %2B0930 References: <20000911093457.H15703@wantadilla.lemis.com> <200009110111.SAA29487@pike.osd.bsdi.com> <20000912091705.O19431@wantadilla.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000911171819.A31089>