Re: the evil interrupt stats monster is still around!

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:Okay, less rough numbers:
:
:122991  104/s   fork
:
:avg fork parent: 0.000157
:avg fork child: 0.002563
:
:so if we assume that the parent always waits for the child, it'll take 0.267 seconds per second (in average) to fork?  That means 1/4 of the time is just spent until the child start running.
:
:the above numbers include vfork, these are without:
:
:avg fork parent: 0.000144
:avg fork child: 0.002556
:
:same, basically.  Maybe teaching sh(1) to use vfork could give some performance improvement?
:
:cheers
:  simon

    There is always something running somewhere when you fork.  Either the
    child is running or the parent is running.  Either way both have to run
    to their completion before the next program can be execed when running
    a shell script since the script serializes everything.

    It tends to be more efficient to allow the parent to continue to run
    (that is, to return from the fork) because there are fewer context
    switches.

    parent		child
    ----------		-----------
    fork()		-
    wait		-
    -			run
    -			run
    -			run
    -			run
    -			exit
    waitreturn

    parent		child
    ----------		-----------
    fork()		-
    -			run
    -			run
    -			run
    wait		-		<<< 2 extra context switches
    -			run
    -			run
    -			exit
    waitreturn

    I would rather not try to optimize programs to use vfork().  There
    just isn't a whole lot of difference between fork and vfork.

    Most of the time spent by the child is not waiting for the parent
    to switch it in, but instead is being spent in execl().  It may be
    possible to speed up execution by making certain dynamic binaries 
    resident (with the 'resident' command).  Everything in /bin is
    statically linked alredy, though, and already execs as fast as it is
    possible to exec a program.  But perhaps pkgsrc is using certain
    binaries internally that are dynamically linked.  I suggest taking
    a good look at what pkgsrc runs.

    There is a fork test program in /usr/src/test/sysperf/fork1.c.
    (make /tmp/fork1 from /usr/src/test/sysperf).  I get around 
    154 uS for a complete fork/exit/wait sequence on my test box.
    A time of 2 mS indicates that something else is going on.. either
    other processes are running or whatever you are execing is taking
    a long time to initialize (which would not be surprising if we are
    talking about /bin/sh here).

    The GNU configure script crap is just that... crap.  In a typical
    pkgsrc build that script will probably be run thousands of times,
    doing the same tests with slow shell scripts over and over and over
    and over and over and over again.  It's really the stupidest gnu thing
    I've ever seen in my life.  It was stupid a decade ago, and its still
    stupid today.

						-Matt