Re: Replicating your tests

["Devon H. O'Dell" <dodell@xxxxxxxxxxxxxxx>]

On Wed, 2005-01-26 at 20:17 +0100, Felix von Leitner wrote: 
> Thus spake Devon H. O'Dell (dodell@xxxxxxxxxxxxxxx):
> > >See "run-bench" and "prep" in the gatling distribution.
> > >You need to pass some large file to mmapbench as argument.
> > >run-bench maps 10000 pages with one gap between them, so with 4k pages
> > >you need a file that is at least 80 megs large.  I used some ISO image I
> > >had lying around.
> > Ah, ok. I'll need to get a bigger disk for this, since the one I'm using 
> > is 4 gigs and barely large enough to do that at the time. I'll see about 
> > doing that.
> 
> You can also use a partition or disk device.
> This test is not about testing the filesystem, this is about mmap
> performance.

*nods* I meant to say I wasn't sure whether I had 80MB free for the
iso ;) I've cleared that up.

I've successfully run the mmap and fork tests on DragonFly... now to see
what I can do regarding testing other operating systems. The current
things I've got are at http://www.sitetronics.com/fefe/

> > Yeah. It's quite strange: http://www.rafb.net/paste/results/Pghall74.html
> 
> Mhh, that trace is not helpful at all and looks like stack corruption.
> Maybe you could do a ktrace and look what the last syscall was?
> 
> Felix

Strangely, when I ktrace, it doesn't seem to die. It times out; going
through the kdump gives me:

59095 gatling  CALL  accept(0x4,0xbfbfd68c,0xbfbfd688)
59095 gatling  RET   accept -1 errno 35 Resource temporarily unavailable

It then times out and closes several (hundred) file descriptors and
loops around doing:

59095 gatling  CALL  gettimeofday(0xbfbfd6a0,0)
59095 gatling  RET   gettimeofday 0
59095 gatling  CALL  gettimeofday(0xbfbfd660,0)
59095 gatling  RET   gettimeofday 0
59095 gatling  CALL  gettimeofday(0xbfbfd640,0)
59095 gatling  RET   gettimeofday 0
59095 gatling  CALL  kevent(0x7,0,0,0xbfbfce78,0x64,0xbfbfce70)
59095 gatling  RET   kevent 0

This seems to be what it does when idling, even before accepting
connections (after it has segfaulted?). After a ktrace, I can't reliably
get it to segfault, or even accept/service connections. I was lucky to
get it to segfault a second time afterwards. If I kill it in GDB and
look at the stack, it looks about the same as the one I placed on rafb:

#0  0x280afdc4 in kevent () from /usr/lib/libc.so.4
#1  0x08054dfd in ?? ()
#2  0x0000000a in ?? ()
#3  0x00000000 in ?? ()
#4  0x00000000 in ?? ()
#5  0xbfbfce48 in ?? ()
bla bla
#2308 0x08056494 in __divdi3 ()
#2309 0x00000001 in ?? ()

I say ``(after it has segfaulted?)'' above because I do not know that
this behavior occurs before the segfault happens, since the behavior of
gatling changes after that, regarding how many connections it accepts /
files it serves / what it wants to do. Since I can't reliably get it to
segfault, I'm having trouble actually being able to ktrace it in its
``virgin'' state. I'll reboot here in a second and see what happens.

Hi, list, I've attached you. Perhaps other people (Matt, Jeff, Simon,
Joerg, Jeroen) might have ideas on what potential issues are.

I wonder if this would act differently if I ran with a non-SMP kernel?
The machine is a dual processor P3.

Kind regards,

Devon H. O'Dell