Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 20 Dec 1997 09:10:37 +0900 (JST)
From:      Michael Hancock <michaelh@cet.co.jp>
To:        Mike Smith <mike@smith.net.au>
Cc:        John-Mark Gurney <gurney_j@resnet.uoregon.edu>, freebsd-hackers@FreeBSD.ORG
Subject:   Re: converting drivers to dynamic memory... 
Message-ID:  <Pine.SV4.3.95.971220085006.10306C-100000@parkplace.cet.co.jp>
In-Reply-To: <199712191417.AAA00414@word.smith.net.au>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SV4.3.95.971220085006.10306C-100000>