From owner-freebsd-smp Mon Feb 28 8:21:48 2000 Delivered-To: freebsd-smp@freebsd.org Received: from mailbox.reptiles.org (mailbox.reptiles.org [198.96.117.155]) by hub.freebsd.org (Postfix) with ESMTP id 2461C37B8A5 for ; Mon, 28 Feb 2000 08:21:44 -0800 (PST) (envelope-from jim@reptiles.org) Received: from localhost (3633 bytes) by mailbox.reptiles.org via sendmail with P:stdio/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) (ident using unix) id for ; Mon, 28 Feb 2000 11:21:40 -0500 (EST) (Smail-3.2.0.108 1999-Sep-19 #3 built 1999-Oct-27) Date: Mon, 28 Feb 2000 11:21:40 -0500 From: Jim Mercer To: Bart van Leeuwen Cc: freebsd-smp@freebsd.org Subject: Re: current working SMP mboards? Message-ID: <20000228112140.L606@reptiles.org> References: <20000228103056.I606@reptiles.org> <38BA9C6D.70769CD@ixori.demon.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <38BA9C6D.70769CD@ixori.demon.nl>; from bart@ixori.demon.nl on Mon, Feb 28, 2000 at 05:03:57PM +0100 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Feb 28, 2000 at 05:03:57PM +0100, Bart van Leeuwen wrote: > > i'm considering the following for 3.4-STABLE (or 4.0-RELEASE): > > ASUS (P2B-DS or P2L97-DS) > > 512M RAM > > 1 x scsi drive for OS/applications > > 5 x 9/18 gig U2W drives under vinum raid5 for data > > First of all, I am using virtually the same config, the p2b-ds works > fine and the scsi stuff works out of the box on both 3.x and 4.0 cool. > > my theory was that with a dual processor, each incantation of the > > application would fire up on alternating processors. > > In quite a few cases that works fine. Don't count on it that the app > will keep running on the same cpu all the time, but when you run some > app twice and they both require cpu time, fbsd will distribute the load > over its 2 cpus. postgresql works with a main process (which coordinates reads/writes to the actual database) and a pairing of client/server processes to actually deal with the query. so, if i fire up a query, there are 3 processes involved, one persistent, two transient. if there are two cpu's, then the processes have more available CPU to get the job done, right? i understand that a single, non-threaded, process will not use cycles from both processes concurrently, but two processes may end up using independent processors for CPU cycles. i gather that the processes might end up on the same CPU, but since i have many queries running at the same time, it would have some advantage to have the processes round-robin'ing the CPU's. > > is this correct? or is SMP effectively useless unless my application > > (primarily postgresql) is multi-threaded. > > Not mostly useless, tho its unlikely to double the performance.. doubling the performance would be way cool, but even a 25% increase in performance would be an acceptable upgrade from where we are now. > Its important to realize that a single instance of an application can > only be run by 2 cpus simultaniously if it is multi threaded. A non > multi threaded app is unlikely to show any performance gain on smp. What > SMP does do in such cases however is make that you can run more on that > machine.. ie, it doesn't get faster, it gets more capacity. (ie, the > capacity to run a 2nd instance of an application without any impact on > the first instance) assuming disk I/O is not a factor (which it may be), if i have a process which is processor intensive, i can run two instances of that process in parallel, right? so if the process takes 30 seconds to complete, then it would be 60 seconds in serial, and 30 seconds (plus something no doubt) in parallel. or are you saying that even when running the processes in parallel, that there are wait-states or something that would make the parallel running time similar to the serial running time? -- [ Jim Mercer jim@reptiles.org +1 416 506-0654 ] [ Reptilian Research -- Longer Life through Colder Blood ] [ Don't be fooled by cheap Finnish imitations; BSD is the One True Code. ] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message