FILEDESC_LOCK() implementation
Robert Watson
rwatson at FreeBSD.org
Wed Jun 21 18:46:34 UTC 2006
On Wed, 21 Jun 2006, John-Mark Gurney wrote:
> Kris Kennaway wrote this message on Mon, Jun 12, 2006 at 01:41 -0400:
>> I fixed mutex profiling to a) not be as wrong and b) not suck so very much,
>> and here is a revised profiling trace from mysql supersmack on a 12 cpu
>> E4500, sorted by ratio of cnt_lock/count; filedesc lock contention (via
>> FILEDESC_[UN]LOCK()) is the major mutex contention problem.
>
> Should we also look at breaking down filedesc lock to have multiple locks
> over the range? I am thinking of writing a program that will have 32
> threads (sun4v) and all threads will be doing heavy i/o, and will be even
> more heavily contested on FILEDESC than the supersmack benchmark would be...
>
> Though this doesn't solve the problem of all 32 threads trying to do i/o on
> a fd in the same block though...
src/tools/tools/netrate/{http,httpd}, running in threaded mode (-t). http is
a client, and accesses lots of independent fds from different threads,
contending the filedesc lock but not a single fd lock, whereas httpd will do
both, due to accepting connections.
I would optimize very carefully here, the trade-offs are tricky, and we may
find that by making locking more complex, we cause cache problems, increase
lock hold periods, etc, even if we decrease contention. I've wondered a bit
about a model where we loan fd's to threads to optimize repeated access to the
same fd by the same thread, but this mostly makes sense in the context of a
1:1 model rather than an m:n model.
Robert N M Watson
Computer Laboratory
University of Cambridge
More information about the freebsd-current
mailing list