From owner-freebsd-hackers Thu Apr 17 14:50:26 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA08423 for hackers-outgoing; Thu, 17 Apr 1997 14:50:26 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id OAA08332 for ; Thu, 17 Apr 1997 14:49:19 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA00534; Thu, 17 Apr 1997 14:46:05 -0700 From: Terry Lambert Message-Id: <199704172146.OAA00534@phaeton.artisoft.com> Subject: Re: Price of FreeBSD (was On Holy Wars...) To: perlsta@fang.cs.sunyit.edu (Alfred Perlstein) Date: Thu, 17 Apr 1997 14:46:04 -0700 (MST) Cc: james@wgold.demon.co.uk, freebsd-hackers@freebsd.org In-Reply-To: from "Alfred Perlstein" at Apr 17, 97 04:17:23 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > database server. And you'd need a growth path beyond uniprocessor > > Intel, which > > free UNIXen (including Linux, as far as I'm concerned) don't have now. > > freebsd doesn't have multiple intel processor support? > is this true? FreeBSD supports a primitive SMP (which is better, by far, than no SMP -- all the really hard work is done). None of the Free UNIX clones support fine grain parallelism (kernel reentrancy on multiple processors, etc.). The current implementations are useful for seperate processes, but do not scale applications well, especially multithreading applications. Most of the win is in "make -j" and multiple "work-to-do" engines, like Apache with some spawned-ahead processes. Unfortunately, the non-reentrancy limits the utility, and lack of ability to imply processor affinity in the scheduler means that you have a 50/50 chance of having to reload all the L1 cache contents as your process migrates, willy-nilly between processors to whichever one was idle when its number came up. Finally, the use of a monolithic mutex instead of a true SMP lock manager (see UNIX for Modern Architectures for huge amounts of data on turnstiles and other useful primitives) means some cache line flushes (minimum) each time the lock is set (since the processor doing the setting must IPI the other processor, which must invalidate cache contents to sync the data in question... like global vnode freelists, etc.). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.