Date: Mon, 12 Nov 2001 18:35:46 -0800
From: Terry Lambert <tlambert2@mindspring.com>
To: Matthew Dillon <dillon@apollo.backplane.com>
Cc: Julian Elischer <julian@elischer.org>, John Baldwin <jhb@FreeBSD.ORG>, Robert Watson <rwatson@FreeBSD.ORG>, freebsd-arch@FreeBSD.ORG
Subject: Re: cur{thread/proc}, or not.
Message-ID: <3BF08702.84DDFFE0@mindspring.com>
References: <Pine.BSF.4.21.0111121608240.94926-100000@InterJet.elischer.org> <200111130030.fAD0Unn07434@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3BF08702.84DDFFE0>