I think this whole thread is loosing its point.

It depends on your application if you're hit by systemcall performance or
not. If you're real-time spend on systemcalls is low enough the user
won't notice if you're system calls introduce a high CPU overhead or
in some cases just addtional latency which amount to a significant fraction of 
the real-time the user will be unhappy.

I've worked for Convex before and we had both kinds of customers, the happy 
ones running CPU intensive jobs and the less happy ones with a systemcall
part.
Yes the systemcall overhead on the parallel machines is significant, but its
the price for running on this architecture.

So if somebody implements a better way of doing syscalls, and it works,
lets use it even if we save only 3% for a kernel build, and 0.1% if 
you run compute intensive jobs. 

On the other hand, I think we can't realy measure how much faster the syscalls 
are in terms of system/user time, because of clock granularity.

In message <199610240537.WAA01660@neteng.engr.sgi.com>  Larry McVoy wrote:
> : I consult to companies that go belly up if their machines don't perform.
> 
> Sheesh, I wouldn't hire you and I do that sort of shit for living.

Hiring or working on optimisations :-)))

[...]
> 
> SGI's NFS get's 20MB/sec over Hippi.  Add the "-o bds" option and you get
> 80MB/sec.  Oh, did I mention that we scale?  3 processes is 190MB/sec.
> That's bytes, not bits, bucky boy.  Cray, my ass.  AFS?  Don't make me
> laugh, what a joke.  AFS is 10-out-of-10 on the bloato meter.

20MB/sec over hippi, I guess with 32k request-size (which is not standard NFS).
NFS got too many extensions for speed-up at the high end, that just comparing 
NFS numbers isn't meaningful.
There are some parameters (max-request size, client caching, server synchronous
or async ...) which influence NFS performance which are independend from
optimisation in the code-path.

On the other hand NFS has a high return on investement for microtuning if it
reduces latency. This doesn't fix the writeback problems Perry is refering 
too below, but a solution for these aren't here yet. (BSD leasing
aproach helps and the xfs project <http://now.cs.berkeley.edu/Xfs/xfs.html>
(not SGI's xfs) approach for distributed caching is also interesting).  

AFS is a solution for some NFS shortcomings in certain envroments, but 
certainly not for performance (besides server-load issuses), and has it's own 
bag of problems.

Making NFS fast helps solving real problems today.

> 
> : NFS isn't built for this. The writeback garbage you have to deal with
> : is horrendous. Algorithm problems -- not something buming code will fix.

True, but as long as somebody comes up with better solution widly 
accpeted as a protocol we've to use it.

[... personal stuff deleted]


One last reminder, the enemy is not somebody working on a free or commercial
operating system, but that guy with ugly glasses trying to swamp the world
with his OS-surrogate, which is neither micro-optimized nor has good
algorithms. 

I think we can all contribute everybody in the area he likes most or can
do best.

Stefan
--
Stefan Grefen                                Tandem Computers Europe Inc.
grefen@hprc.tandem.com                       High Performance Research Center
You should never bet against anything in science at odds of more than
about 10^12 to 1.
                -- Ernest Rutherford