Re: the evil interrupt stats monster is still around!

["Simon 'corecode' Schubert" <corecode@xxxxxxxxxxxx>]

Matthew Dillon wrote:
>     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.

No, my point was that the child takes some time to even return from the fork, despite the parent already wait()ing.  There is some gap involved where the system seemingly just schedules somebody else instead or so.

>     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

Ah, I see the point.  This however does not explain why the child takes some time to be scheduled.

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

I think our vfork is not completely optimized.  We could for instance make vfork not COW the vmspace, because the user is only allowed to call _exit and exec().  I don't think we are doing this right now.

>     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().

That's actually not true:

Total runtime 1171.642231 sec

122991  104/s   0.002616        321.756458      fork_child
122991  104/s   0.000148        18.181783       fork_parent
112576  96/s    0.000235        26.489667       execve
239985  204/s   0.000080        19.174908       open
(etc)

total exec time is not very high.

>     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).

I'm not talking about fork/exec performance.  This is from a build kdump, taking the CALL and RET times and calculating the duration of the syscall.

cheers
 simon

--
Serve - BSD     +++  RENT this banner advert  +++    ASCII Ribbon   /"\
Work - Mac      +++  space for low €€€ NOW!1  +++      Campaign     \ /
Party Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \
Dude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \