From owner-freebsd-hackers Fri Dec 19 16:12:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA04224 for hackers-outgoing; Fri, 19 Dec 1997 16:12:07 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA04169 for ; Fri, 19 Dec 1997 16:11:57 -0800 (PST) (envelope-from michaelh@cet.co.jp) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.8/CET-v2.2) with SMTP id AAA10445; Sat, 20 Dec 1997 00:10:37 GMT Date: Sat, 20 Dec 1997 09:10:37 +0900 (JST) From: Michael Hancock To: Mike Smith cc: John-Mark Gurney , freebsd-hackers@FreeBSD.ORG Subject: Re: converting drivers to dynamic memory... In-Reply-To: <199712191417.AAA00414@word.smith.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 20 Dec 1997, Mike Smith wrote: > > > > Forget the btree model; it's not going to fly in the face of a direct > > > > reference approach. > ... > > > when did I ever say that we should in the long run choose using a > > > btree over the "correct" way to do it?? I only said it would require > > > > Hashing for example is very good in the kernel, even in cases where you > > think btrees would be better. The reasoning is along the lines of what > > Koshy was talking about. If you can abstract things well enough so that > > you can make a change later on very easily, by all means carry on. > > Someone will find a use for your Btrees elsewhere most likely. > > ... but of course dereferencing a pointer (hardly) requires any > parallelisation. Why go to all this complexity when all you are > interesting in doing is taking an opaque token and obtaining the > address of a (reasonably non-motile) structure? Sorry, I haven't been following the thread. I jumped in when I noticed talk about data structures. If the structure is read-only then you don't have a problem. If it is volatile, then you do need to lock down structures and hashes are good because you can just lock the bucket list header localizing contention to the bucket. > Perhaps I'm missing something; let's take the opposite tack. What > advantages (in real terms) do we gain by storing the address of the > control structure in some fashion and then requiring a token in order > to obtain it? Is this advantage significant in the face of the not > insubstantial performance penalties? I think the opacity benefits are significant. I also think that "some fashion" is very important in the kernel. People expect the kernel to work correctly and perform very well. Regards, Mike Hancock > mike > > -- michaelh@cet.co.jp http://www.cet.co.jp CET Inc., Daiichi Kasuya BLDG 8F 2-5-12, Higashi Shinbashi, Minato-ku, Tokyo 105 Japan Tel: +81-3-3437-1761 Fax: +81-3-3437-1766