Reducing system calls overhead

[Dennis L. Mumaugh]

In article <7622 at boring.cwi.nl> jack at cwi.nl (Jack Jansen) writes:
        I don't think that the solution you pose for simple calls
        would  help  anything.  First, calls like getuid, getpid,
        etc. are very rare, and, second, there's a  much  simpler
        solution for these calls: just do the call the first time
        and cache the result.

1).  We have a system call trace program that reports on each and
every system call a process makes -- useful for support to figure
out what a program  REALLY  is  doing.  The  most  commonly  used
system call seems to be
	lseek(fd,0L,1) ==> tell me where I am.
I have seen one program issue  50  of  these  in  a  row  without
intervening  I/O  or  other system calls. [Result of the standard
I/O system design.]

Caching the lseek and redesign of the I/O library could be a real
win.  With the release of the system call tracer in the future as
a standard tool, it will be possible for developers  to  look  at
dynamic program behaviour and catch some of these problems.

        Unfortunately the quick-entry system  doesn't  work  here
        because both these calls can block....


2).  Fix the sysent table with a flag  for  blocking/non-blocking
syscalls.  On guarenteed non-blocking calls use a faster process.
On the WE32100 chip with gate tables, it was possible to  specify
different  entry  points  for  each  system call.  The developers
chose to use a single entry point for all system calls,  BUT  the
hardware  does  support all different entry points.  Thus syscall
handling  could  be  re-written  to  allow  light-weight  syscall
handling.

3).  Or, map the user's u-block (and proc table entry) into  some
funny  virtual  area  of the user's space (read-only).  Then many
syscalls could be eliminated in favor of simple code:

Instead of getpid() being a system call it becomes:
	#define getpid() (PROC->p_pid)
and similarly:
	#define getppid() (PROC->p_ppid)
	#define getuid() (UBLOCK->u_uid)
and so forth.

With better design of the users virtual memory  space  one  could
"allow"  a  lot less kernel activity.  The trade-off of course is
the necessity of having  enough  MMU  entries  available,  kernel
interlocking  so  the  extra  pages are there when needed and the
extra setup for a context switch.

-- 
=Dennis L. Mumaugh
 Lisle, IL       ...!{att,lll-crg}!cuuxb!dlm  OR cuuxb!dlm at arpa.att.com