From owner-freebsd-hackers Wed Jun 23 21:45:50 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 6330B14F43 for ; Wed, 23 Jun 1999 21:45:47 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id VAA53565; Wed, 23 Jun 1999 21:45:43 -0700 (PDT) Date: Wed, 23 Jun 1999 21:45:42 -0700 (PDT) From: Julian Elischer To: "Russell L. Carter" Cc: hackers@FreeBSD.ORG Subject: Re: Microsoft performance (was: ...) In-Reply-To: <199906240421.VAA94722@psf.Pinyon.ORG> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 23 Jun 1999, Russell L. Carter wrote: > > %Basically there are some applications and benchmarks for which FreeBSD > > uh, "benchmarks" only, until evidence is produced otherwise. > > Tuning for benchmarks has been around a long long time. > > People get worked up about this because the people who give > out the money to buy the systems use benchmarks to decide > whom to give the money to. > > It's really, really stupid to rely on generic benchmarks. > > But people do, anyway. So I guess whistle and some others should > invest in tuning for the benchmarks. Like jupiter, eh? Or maybe > Apple. > > But for the rest, I wouldn't panic. > > In fact, there's probably some interesting kernel architecture > issues here. Let's hear them, now! If I wanted secrecy about > architecture details there's a shitload less time consuming > ways to do it then follow FreeBSD. ok here are some of the problems.. Matt's changes allow dd to copy data at 2.5 times the rate it did before. I consider dd to be an application. The problem is due to resource handling in the kernel and results in large amounts of Idle CPU time. Another primary problem with the FreeBSD kernel (being addressed by Kirk) is that after writing a file, once the data has been queued for IO you cannot read the data in that file (even though it is present) until the IO is complete. With 64 tags, it is concievable that this could take a half second on a modern disk. These are problems shown up by the benchmarks but which can be shown to affect ordinary operations. There are other problems related to SMP and the GKL.. e.g.. two processes cannot access buffers at the same time, even though they are both present , because only one of them is allowed in the kernel at a time. Therefore One processor will spend a bunch of time at idle.. > > Russell > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message