Re: the evil interrupt stats monster is still around!

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:Yah, quite possible.  However, why'd that only happen for for fork and not for other possibly blocking syscalls (or vfork)?  I think we need some better, performance-counter based tracing tools, rather than plain kdump output.

    There really isn't a whole lot of difference between fork and vfork,
    but I noticed at the end of your dump that both fork and vfork had
    much shorter delays then what I saw at the beginning of your dump.
    

:>     Are you running anything in parallel during this test or running
:>     a parallel build of some sort?
:
:I don't remember anymore, probably there was a build going on in parallel.  But again, I'm not trying to benchmark, I'm trying to find a cause for the slow build speed.
:
:cheers
:  simon

    Its called a script titled 'gnu configure'.  Do a systat -vm 1 and look
    at the name cache hit stats.  Everything bmake, gcc, and especially the
    gnu configure script do is extremely filesystem intensive.  And in the
    case of gnu configure, also mostly redundant.

						-Matt