From owner-freebsd-arch Mon Nov 12 18:35: 5 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gull.prod.itd.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by hub.freebsd.org (Postfix) with ESMTP id A7C8E37B417; Mon, 12 Nov 2001 18:34:58 -0800 (PST) Received: from dialup-209.247.141.234.dial1.sanjose1.level3.net ([209.247.141.234] helo=mindspring.com) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 163TPc-0003xn-00; Mon, 12 Nov 2001 18:34:56 -0800 Message-ID: <3BF08702.84DDFFE0@mindspring.com> Date: Mon, 12 Nov 2001 18:35:46 -0800 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dillon Cc: Julian Elischer , John Baldwin , Robert Watson , freebsd-arch@FreeBSD.ORG Subject: Re: cur{thread/proc}, or not. References: <200111130030.fAD0Unn07434@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Matthew Dillon wrote: > There are two huge advantages to using pool mutexes: > > * No structural overhead. Zip. Zero. Zilch. Nada. > > * The mutex itself is stable storage, even if the address > is not, so you can use it to verify the second pointer when you > have a pointer to a (stable) structure containing a field which > is a pointer to an (unstable) structure. They are a solution to the retrofit problem. I.e. you use them when you would rather kludge around the problem instead of having to refactor the code. > There are two disadvantages: > > * Possible non-optimal cache mastership behavior. However, this > is not a major disadvantage since it can be addressed by > increasing the pool size. See my other post... this looks like a fix, but it doesn't scale, and it limits the system by default, and grossly complicates tuning for optimal performance for a particular task. > * Slightly greater overhead to calculate the hash index and obtain > the address of the pool mutex before obtaining or releasing it. > > The pool mutex hash function would be something simple based on > (int)ptr. You could pick a computationally trivial hash to avoid this; it's fairly irrelevant to the argument, either way, I think. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message