Date: Mon, 12 Nov 2001 19:17:18 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
To: Terry Lambert <tlambert2@mindspring.com>
Cc: John Baldwin <jhb@FreeBSD.ORG>, Julian Elischer <julian@elischer.org>, freebsd-arch@FreeBSD.ORG, Robert Watson <rwatson@FreeBSD.ORG>
Subject: Re: cur{thread/proc}, or not.
Message-ID: <200111130317.fAD3HIE07916@apollo.backplane.com>
References: <XFMail.011112162432.jhb@FreeBSD.org> <3BF085EC.AEE7DE9C@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
: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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200111130317.fAD3HIE07916>