Re: Replicating your tests
On Wed, 2005-01-26 at 20:17 +0100, Felix von Leitner wrote:
> Thus spake Devon H. O'Dell (dodell@sitetronics.com):
> > >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
討論串 (同標題文章)