Re: syscall messaging interface API

[David Schultz <dschultz@xxxxxxxxxxxxxxxx>]

On Wed, Jul 23, 2003, Bill Huey wrote:
> On Wed, Jul 23, 2003 at 02:32:30PM -0700, Matthew Dillon wrote:
> > : Didn't the L4 folks find a way to make system calls on Pentiums without using
> > :software interrupts?  Isn't this like 10x faster?
> > :
> > :I need to read stuff at the Pistachio site again but I think I am correct.
> > :Any chance that could get integrated into DflyBSD?  [sorry for shortenting :)]
> > 
> >     There are a number of ways to get into kernel mode.
> > 
> >     Call Gates -	Really slow
> >     Trap Gates -	Reasonable
> >     SYSENTER -		About twice as fast as a trap gate but there are
> > 			issues (typical intel stupidity)
> > 
> >     Int0x80, 0x81, etc... those are trap gates.  Overhead on a 1GHz P3
> >     is about 100ns to get in and 100ns to get out.
> > 
> >     We are going to stick with trap gates for the foreseeable future.  There
> >     are plenty of other ways to make system calls more efficient in those
> >     situations that require it, like adding a feature to queue several
> >     system calls at once, or by chaining messages, etc...  99.9% of
> >     all programs ever written in the entire history of mankind would not
> >     have a noticeable improvement in performance so it just isn't worth
> >     worrying about.
> 
> Syscalls speed is critical if you use a hybrid user/kernel space thread
> blocking/cond-var primitive to do 1:1 threading. Linux's "futex" mechanism
> exploits and optimizes it to serve the "greater threading good". :)
> 
> It shouldn't be ignored.

Even in Linux, the contested case is rare.  I've found that a
*busy* login server handles on the order of 10,000 syscalls per
second, while syscall overhead is on the order of 500 ns.  The
optimized syscall path in Linux 2.4.9 saves about 11% over FreeBSD
4.X, at the expense of special cases for syscalls with more than
four arguments and other kludges.  So the potential improvement
we're talking about here is probably well under 0.01%.

Even if you did manage to come up with a program where ``syscall
throughput'' is significant, batching the calls as Matt suggested
would provide much better performance benefits than microoptimization.