Xref: utzoo comp.unix.wizards:10705 comp.os.misc:489
Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!ll-xn!mit-eddie!killer!vector!rpp386!jfh
From: jfh@rpp386.UUCP (The Beach Bum)
Newsgroups: comp.unix.wizards,comp.os.misc
Subject: Re: Reducing system calls overhead
Summary: lightening system call overhead ...
Message-ID: <5827@rpp386.UUCP>
Date: 26 Aug 88 00:59:19 GMT
References: <21606@ccicpg.UUCP>
Reply-To: jfh@rpp386.UUCP (The Beach Bum)
Organization: HASA, "S" Division
Lines: 27

In article <21606@ccicpg.UUCP> goshen@ccicpg.UUCP (Shmuel Goshen) writes:

[ thoughts on lightening the system overhead of system calls ]

>I am looking for opinions on these approaches. My main concern is side 
>effects caused by eliminating signal delivery and rescheduling until 
>a "software forced exception" or a *heavy* system call is executed 
>by the process. (Consider, for example, a program running getpid() 
>calls in a loop).

i did optimization work on trap() to lighten the syscall overhead.
the first approximation was to check the number of arguments which
where expected and jump around the code which copied the arguments.

the second approximation checked the number of return arguments,
and so on.  i believe the final solution (which i had nothing to
do with) added several additional fields to the sysent structure
to indicate how comlex the call was.

the net result was a big boost in benchmark performance.  i don't
remember WHICH system call a certain benchmark company used to
measure overhead, but that metric was improved by 100%.
-- 
John F. Haugh II (jfh@rpp386.UUCP)                           HASA, "S" Division

    "If the code and the comments disagree, then both are probably wrong."
                -- Norm Schryer