Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 23 Jun 1999 21:45:42 -0700 (PDT)
From:      Julian Elischer <julian@whistle.com>
To:        "Russell L. Carter" <rcarter@pinyon.org>
Cc:        hackers@FreeBSD.ORG
Subject:   Re: Microsoft performance (was: ...) 
Message-ID:  <Pine.BSF.3.95.990623213838.993R-100000@current1.whistle.com>
In-Reply-To: <199906240421.VAA94722@psf.Pinyon.ORG>

next in thread | previous in thread | raw e-mail | index | archive | help


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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.990623213838.993R-100000>