From owner-freebsd-arch Mon Nov 12 19:17:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id BD55D37B405; Mon, 12 Nov 2001 19:17:19 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fAD3HIE07916; Mon, 12 Nov 2001 19:17:18 -0800 (PST) (envelope-from dillon) Date: Mon, 12 Nov 2001 19:17:18 -0800 (PST) From: Matthew Dillon Message-Id: <200111130317.fAD3HIE07916@apollo.backplane.com> To: Terry Lambert Cc: John Baldwin , Julian Elischer , freebsd-arch@FreeBSD.ORG, Robert Watson Subject: Re: cur{thread/proc}, or not. References: <3BF085EC.AEE7DE9C@mindspring.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :things like struct socket allocations, which weren't updated :when kevent came in and changed the size of the structure :and therefore made the previous optimal cluster allocation :block pessimal instead. : :Pool mutexes have the same problem that the fixed hash size :for TCP connections has, in that you end up with relatively :large collision domains when you get to a relatively large :number of objects being hashed. Well, I have to disagree. The primary scaling issue for pool mutexes is against the number of cpu's, not the number of structures, and the number of cpu's is relatively static. I agree that the hash function needs to be chosen carefully to maximize performance, but the advantage is that this (and other tricks) can be done inside the API, without having to mess around with anything outside the API. I think we have a far worse problem with structural bloat right now. Far, far worse. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message