Date: Thu, 2 Aug 2007 18:44:45 -0700 From: Alfred Perlstein <alfred@freebsd.org> To: Jeff Roberson <jroberson@chesapeake.net> Cc: arch@freebsd.org, Kris Kennaway <kris@obsecurity.org> Subject: Re: Fine grain select locking. Message-ID: <20070803014445.GS92956@elvis.mu.org> In-Reply-To: <20070802174819.S561@10.0.0.1> References: <20070702230728.E552@10.0.0.1> <20070703181242.T552@10.0.0.1> <20070704105525.GU45894@elvis.mu.org> <20070704114005.X552@10.0.0.1> <20070729180722.GB85196@rot26.obsecurity.org> <20070802174819.S561@10.0.0.1>
next in thread | previous in thread | raw e-mail | index | archive | help
* Jeff Roberson <jroberson@chesapeake.net> [070802 17:52] wrote: > > I believe filedescriptor locking is the place where we are most lacking. > The new sx helped tremendously. However, this is still going to be a > scalability limiter. I have looked into both linux and solaris's solution > to this problem. Briefly, linux uses RCU to protect the list, which is > close to ideal as this is certainly a read heavy workload. Solaris on the > other hand uses the actual file lock to protect the descriptor slot. So > they fetch the file pointer, lock it, and then check to see if they lost a > race with the slot being reassigned while they were acquiring the lock. > This approach is perhaps better than rcu in many cases except when the > descriptor set is expanded. Then they have to lock every file in the set. Certainly this is an extreme edge case... ? I could see it happening if we started with low limits, but perhaps by keeping counters/stats we could tell people how to tune their systems, or even autotune them. -Alfred
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070803014445.GS92956>