Call for thread testers

[Daniel Eischen]

On Thu, 28 Aug 2003, David Xu wrote:

> On Thursday 28 August 2003 07:57, Daniel Eischen wrote:
> > Yes, perhaps my kernel was a bit out of date.  I also had
> > forgotten I had libc_r mapped to libkse with libmap.conf,
> > so the libc_r tests were actually using libkse!  I re-ran
> > the tests on a different box, single PIII 800MHz, 512MB RAM.
> > They look better, although libthr still doesn't give consistent
> > results.
> >
> >                        Run 1         Run 2          Run 3
> >   -----------------------------------------------------------
> >   libc_r       real    0m13.739s     0m13.739s      0m13.882s
> >                user    0m3.330s      0m3.302s       0m3.394s
> >                sys     0m9.858s      0m9.893s       0m9.820s
> >   -----------------------------------------------------------
> >   libkse(M:N)  real    0m11.977s     0m12.199s      0m12.097s
> >                user    0m3.248s      0m3.081s       0m2.857s
> >                sys     0m8.190s      0m8.517s       0m8.575s
> >   -----------------------------------------------------------
> >   libkse(1:1)  real    0m11.972s     0m12.044s      0m12.035s
> >                user    0m3.198s      0m2.980s       0m3.183s
> >                sys     0m8.244s      0m8.480s       0m8.282s
> >   -----------------------------------------------------------
> >   libthr       real    0m34.180s     0m16.193s      0m34.119s
> >                user    0m5.075s      0m3.874s       0m5.255s
> >                sys     0m28.286s     0m11.626s      0m28.038s
> >   -----------------------------------------------------------
> >
> > libkse(1:1) and libkse(M:N) are about equal, and slightly
> > better than libc_r.  I can't explain libthr results.
> 
> Use a kernel without witness compiled in, libthr should be faster
> than this result.

Well, what got me was the variance in time.  Most of the time
it takes twice as long.  And it doesn't seem to hang for a few
seconds at any one point; it plods along consistently, just
twice as slow overall.  It could be mutex contention and
false wakeups or something...

> But I always can not finish this test for libthr on my SMP machine,
> in most time, it will deadlock, so I can not give you a reliable result.

It hangs in my thread yield test also; don't know why.

-- 
Dan Eischen