Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!hplabs!hp-pcd!orstcs!go
From: go@orstcs.cs.ORST.EDU
Newsgroups: comp.os.minix
Subject: Re: MINIX kernel profiling
Message-ID: <505100016@orstcs>
Date: Sat, 9-May-87 12:32:00 EDT
Article-I.D.: orstcs.505100016
Posted: Sat May  9 12:32:00 1987
Date-Received: Mon, 11-May-87 03:02:13 EDT
References: <134@wldrdg.UUCP>
Lines: 22
Nf-ID: #R:wldrdg.UUCP:-13400:orstcs:505100016:000:1168
Nf-From: orstcs.cs.ORST.EDU!go    May  9 09:32:00 1987


Just a thought regarding the overhead numbers:  I did a "hand job" on the
profiling of the trip through the message code for clock interrupts, and
it suggested to me that as much as 75% of the time spent handling a
simple clock tick interrupt could be elided by some simple tests
(e.g. don't validate parameters if message is coming from INTERRUPT.)
I truly don't want to change the "structure" of the message passing --
it is VERY elegant the way it is and should appear "orthogonal" from
the very bottom-most level.

However, your numbers may be slightly tainted regarding this sendrec
overhead, since you will not see the time used by the clock interrupt
within that routine.  Granted, most of the other uses of sendrec are
small --  a few for each system call and most system calls are for disk
i/o which moves data in fairly large chunks.  If someone could work up
the steam, they could connect their PC to a logic analyzer with code
frequency tracing and get some impartial numbers.

I applaud your efforts, though.  I thought of doing something like that
but just couldn't work up the energy.
Gary Oliver
...!hplabs!hp-pcd!orstcs!go		(Until they pull my plug)