From owner-freebsd-stable Wed Apr 28 14:58:53 1999 Delivered-To: freebsd-stable@freebsd.org Received: from guru.phone.net (guru.phone.net [209.157.82.120]) by hub.freebsd.org (Postfix) with SMTP id D71C715793 for ; Wed, 28 Apr 1999 14:58:51 -0700 (PDT) (envelope-from mwm@phone.net) Received: (qmail 9348 invoked by uid 100); 28 Apr 1999 21:58:51 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 28 Apr 1999 21:58:51 -0000 Date: Wed, 28 Apr 1999 14:58:51 -0700 (PDT) From: Mike Meyer To: Tom Cc: Matthew Reimer , freebsd-stable@freebsd.org Subject: Re: MFC pthreads before 3.2 is released? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 28 Apr 1999, Tom wrote: > It doesn't really depend on postgresql at all. If your process mix is > cpu intensive, you will get a benefit. If your process mix is > kernel/syscall intensive, then you won't get much benefit as only one > process can be active in the kernel at a time. Now, are your postgresql > processes cpu or kernel intensive? Depends on what you do. That I believe - that's why I listed the other things going on. The note on the Postgres list is what made me stop to think about this. The claim there was that postgres - in a syscall intensive app - actually *slowed down* with the second processor enabled. I've seen similar effects elsewhere. Early versions of Ultrix turned up better numbers on multiuser benchmarks if you turned one processor off. In practice - in that environment - someones long-running number-cruncher grabbed the second processor pretty quickly, having pretty much the same effect as disabling it. Since they wind up getting faster real-time turnaround off the 8820 than they did of the Cray X/MP-14, everyone was happy. The real question isn't how much benefit I'll see - it's whether or not there are job mixes that will cause the system to seem slower.