Date: Wed, 21 Jun 2006 13:19:27 -0700 From: Paul Allen <nospam@ugcs.caltech.edu> To: Robert Watson <rwatson@freebsd.org> Cc: current@freebsd.org Subject: Re: FILEDESC_LOCK() implementation Message-ID: <20060621201927.GJ28128@groat.ugcs.caltech.edu> In-Reply-To: <20060621194412.N8526@fledge.watson.org> References: <20060612054115.GA42379@xor.obsecurity.org> <20060621183543.GC82074@funkthat.com> <20060621194412.N8526@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
>From Robert Watson <rwatson@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060621201927.GJ28128>