the evil interrupt stats monster is still around!

[Simon 'corecode' Schubert]

Matthew Dillon wrote:
:ktrace.  These are real numbers, not a microbenchmark.  There might be a little bit of load interfering, dunno.  You can grab the dump from <http://chlamydia.fs.ei.tum.de/~corecode/unsorted/kdump.out.bz2>
    Use kdump -R !!! 
heh.  well, the absolute ones help me process the time automatically.

    What it looks like is happening is that there are other processes
    running that get the cpu after the fork/wait4, before the child
    gets the cpu.  Insofar as I can tell it looks like there is a cpu-bound
    program running that is simply not making any system calls to be traced,
    or is not being traced.
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.

    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
--
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   / \