Date: Tue, 21 May 1996 19:17:54 -0600 From: Warner Losh <imp@village.org> To: "David S. Miller" <davem@caip.rutgers.edu> Cc: terry@lambert.org, jehamby@lightside.com, jkh@time.cdrom.com, current@FreeBSD.org, hackers@FreeBSD.org Subject: Re: Congrats on CURRENT 5/1 SNAP... Message-ID: <199605220117.TAA01774@rover.village.org> In-Reply-To: Your message of Tue, 21 May 1996 14:08:41 EDT
next in thread | raw e-mail | index | archive | help
: You see there will always be something else, you cannot eliminate all : the contention problems (ever think about what would be involved : in implementing a low contention SMP locking scheme for the entire : berkeley networking stack?). You've dug yourself into a hole and are : trying now to dig yourself out, you may get partway out but you must : stay in the hole inevitably. I think the figure that Solbourne was telling some poeple was about four or six man years to come up with a true SMP OS with fine grained locking. I seem to recall that about a year of that was for the networking code in SunOS 4.1.x. The OS/MP kernels scaled well past 4 CPUs and I think the most was something like 12 or so. I'm not sure if any larger number of CPU machines were ever built or not. I know that on a 3CPU system we got nearly 3.0 times three 1 CPU systems of the same speed (something like 2.9 for the specmarks). For an 8 CPU system it wasn't as good (7.5ish) but still well worth it. For a 12 CPU system, I think the number was down to 11ish, but most of that work was done after I left Solbourne. None of these numbers prove that it was a low contention TCP stack, but I know that an interesting number of companies still use big Solbourne Iron for their DP needs. It was a seriously non-trivial amount of work to get thigns to this point. This was the number one reason that the lag between Sun FCS and Solbourne FCS was so large. Don't know if clustering is the answer because then you get a lot of data copying overhead that is free on a shared memory MP box. Does lock contention get so bad that you actually win by data copying for huge numbers of CPUs? I don't know, but it is certainly an area of research that will be fruitful for a few years. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605220117.TAA01774>