Reducing system calls overhead

Jerry Aguirre jerry at olivey.olivetti.com
Wed Sep 7 14:24:27 AEST 1988


In article <21606 at ccicpg.UUCP> goshen at ccicpg.UUCP (Shmuel Goshen) writes:
>
>The second approach would be to introduce a simple and quick interface
>for "light weight" system calls (like getpid(), umask() etc'), which 
>perform simple tasks and never sleep.  This quick interface will run 
>in kernel mode, thus enabling access to kernel data structures, but 
>will not include operations like saving the context (setjmp), signal 
>delivery and allowing rescheduling upon return from the call. 
>The net effect is almost as having the system call run in user mode. 

I once did this for a proprietary OS (not Unix).  The general system
call and return took slightly more than 300us.  I added a test in the
software interupt routine to check if the request was a simple one.  If
it was then the code would preform the service and return directly to
the caller.  This reduced the time to slightly more than 30us.

This was all done with interupts disabled but I calculated that the
routine did the requested service and returned in less time than the
normal code required to save context and enable interupts.

For that OS this was a big win.  In effect it had system calls doing
system calls so many of the common calls had their overhead multiplied
several times doing trivial functions like getting and returning
parameters.  (This was a result of an attempt to maintain structure
while limited to a 16 bit logical address space.)

There are certainly several Unix system calls that can be considered
trivial (getpid, umask, gettimeofday) but as others have pointed out
they are not normally used very often.  The exact overhead in checking
for trivial services is going to depend on the hardware facilities
available.  In some cases it may be zero.  In others it is going to add
a small amount of overhead to every non-trivial call.  Only measurements
under a "normal" load are going to tell if the result is a net gain.

It would certainly look nice on some of the benchmarks though.
				Jerry Aguirre



More information about the Comp.unix.wizards mailing list