Date: Tue, 12 Sep 2000 09:17:05 +0930 From: Greg Lehey <grog@lemis.com> To: John Baldwin <jhb@pike.osd.bsdi.com> Cc: 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: <20000912091705.O19431@wantadilla.lemis.com> In-Reply-To: <200009110111.SAA29487@pike.osd.bsdi.com>; from jhb@pike.osd.bsdi.com on Sun, Sep 10, 2000 at 06:11:25PM -0700 References: <20000911093457.H15703@wantadilla.lemis.com> <200009110111.SAA29487@pike.osd.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[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. That's exactly my point, though I'd be inclined to replace "headache" with something stronger. We really need to come up with a strategy for adding mutexes, or we're going to be in trouble. Take a look at BSD/OS's sys/proc.h for an example of how complicated things can get: /* * Description of a process. * * This structure contains the information needed to manage a thread of * control, known in UN*X as a process; it has references to substructures * containing descriptions of things that the process uses, but may share * with related processes. The process structure and the substructures * are always addressible except for those marked "(PROC ONLY)" below, * which might be addressible only on a processor on which the process * is running. * * * - not yet protected * a - only touched by curproc or parent during fork/wait * b - created at fork, never chagnes * c - locked by proc mtx * d - locked by allproc lock * e - locked by proc tree lock * f - session mtx * g - process group mtx * h - pid hash table mtx * i - by curproc or the master session mtx * j - locked by sched mtx * k - either by curproc or a lock which prevents the lock from * going way, such a (d,e). * l - the attaching proc or attaching proc parent. * m - Giant * n - not locked, lazy * o - time lock */ I've been wondering whether we shouldn't associate mutexes with data structures rather than code. It's possible that it would make it easier to avoid deadlocks. Thoughts? Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000912091705.O19431>