FILEDESC_LOCK() implementation
Paul Allen
nospam at ugcs.caltech.edu
Wed Jun 21 20:19:29 UTC 2006
>From Robert Watson <rwatson at freebsd.org>, Wed, Jun 21, 2006 at 07:46:33PM +0100:
> 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.
I apologize for not understanding all of the uses of the FILEDESC lock but,
isn't the more obvious partitioning per-cpu: each cpu may allocate from a
range of fd, which cpu cache used depends on where the thread happens
to be running. When closing a fd, it is returned to the local (possibly
different cpu cache). A watermark is used to generate an IPI message to
rebalance the caches as needed.
More information about the freebsd-current
mailing list