From owner-freebsd-arch Mon Sep 11 16:48: 0 2000 Delivered-To: freebsd-arch@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 80B7037B422; Mon, 11 Sep 2000 16:47:25 -0700 (PDT) Received: (from grog@localhost) by wantadilla.lemis.com (8.11.0/8.9.3) id e8BNl5281326; Tue, 12 Sep 2000 09:17:05 +0930 (CST) (envelope-from grog) Date: Tue, 12 Sep 2000 09:17:05 +0930 From: Greg Lehey To: John Baldwin Cc: 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: <20000912091705.O19431@wantadilla.lemis.com> References: <20000911093457.H15703@wantadilla.lemis.com> <200009110111.SAA29487@pike.osd.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i 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 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [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 freebsd-arch" in the body of the message