From owner-freebsd-smp Sun Sep 14 21:28:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA27199 for smp-outgoing; Sun, 14 Sep 1997 21:28:36 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id VAA27187 for ; Sun, 14 Sep 1997 21:28:32 -0700 (PDT) Received: (qmail 29752 invoked by uid 1000); 15 Sep 1997 04:28:53 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199709150355.UAA24481@implode.root.com> Date: Sun, 14 Sep 1997 21:28:53 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: dg@root.com Subject: Re: SMP in FreeBSD 3.x.x Cc: Terry Lambert , missmanp@milo.cfw.com, freebsd-smp@freebsd.org Sender: owner-freebsd-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi David Greenman; On 15-Sep-97 you wrote: > >:-) was that aroud 30 processors is where scalability will fall off. We > >used Dynix + Oracle for O/S application model. Processor was Pentium. > >If > >I remember correctly, the P6-200 has worse instructions/memory/IO > >bandwidth > >ratios than Pentiums-66 does. That led to the conclusion that we will > >not > >grow beyond 30 either. I will not go into what the initial P7 was > >supposed > > This contradicts a paper that was given at a recent Usenix-sponsored > conference that shows that the amount of main memory traffic in P6 > systems > is *dramatically* reduced over Pentium systems. I forget the exact > ratio, > but it is something like 1/5th. This is entirely due to the superior > cache > architecture of the P6. For in-cache applications, this is very true. For RDBMS applications this is totally immaterial; In a typical database operation, very little of the data resides in the cache. I hope I am not revealing some proprietary data, but something like an RDBMS requires abot 2MB cache to handle the text. The dataset is so much larger that one can assume the cache does not exist. For example, in a typical RDBMS scenario, one may do a full table scan on several terabytes of data. The cache size (256-512KB) of a P6 is not exactly meaningful here. Also, if you look at the text size of something like Oracle, you will see 8-10MB, The cache represents 2-4% of that (in a P6). Before you mention ordered linking, shared libraries, etc. I'll haste to say that when I last looked, Oracle was statically linked (for a mix of good and bad reasons) and we used to run bets on the number of never-called functions in the code (the real number was about 1,100 or so). Also, the typical RDBMS source is not exactly compiant with KNF and not highly optimized for efficiency. After all, not many FreeBSD'ers work there :-) Although at least one Linux contributor does. I'd better stop now... --- Sincerely Yours, (Sent on 14-Sep-97, 21:19:34 by XF-Mail) Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313