On Tue, 13 Aug 2002, Richard Earnshaw wrote:

> Now it would be interesting to know why those numbers (particularly the
> protection fault timings) have degraded with this change.

The protection fault degradation is, I think, an issue of how it's
measured.  It's something like

T(protfault+sigcatch) - (T(kill+sigcatch) - T(kill))

T(kill+sigcatch) has gone down lots (that's "sig hndl" in the table), and
my suspicion is that there's some bit of sped up code in that which
neither kill on its own nor protfault+sigcatch executes, so that the
apparent time for protfault got larger.  I'm open to better suggestions.

The page fault timing might be a consequence of getrusage having got lots
faster, since lat_pagefault calls getrusage twice per pagefault, and hence
has a lot of overhead to subtract out.  If the overhead is inconsistent in
some way, it might account for some of the degradation (though the
degradation is actually very large in absolute terms).

> Those and the
> TCP conn timings for SA are significantly worse.

TCP conn is only run a very few times, because kernels tend to accumulate
dead TCP connections, which can slow things down.  I should probably run
that test a couple more times

>  I suspect the "mmap
> reread" timing may just be a statistical glitch, but you never know...

Maybe.  The open/close timing is actually slightly worrying, since I can't
come up with an excuse for it.

-- 
Ben Harris                                                   <bjh21@netbsd.org>
Portmaster, NetBSD/acorn26           <URL:http://www.netbsd.org/Ports/acorn26/>