FILEDESC_LOCK() implementation
John-Mark Gurney
gurney_j at resnet.uoregon.edu
Wed Jun 21 20:21:55 UTC 2006
Robert Watson wrote this message on Wed, Jun 21, 2006 at 19:46 +0100:
> 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.
Well, in my lfhttpd, I'd only ever have one thread accepting connections,
but then I'd have tons of threads contending on the kqueue fd...
> 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.
And wouldn't work for everyone pounding for kq... Hmmm.. we could remove
kq from the fd model too...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
More information about the freebsd-current
mailing list