[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[nptl] Re: New results
Hallo Sébastien,
I do believe it is a kernel problem in the scheduler.
But I'd like to write the last test before I can
confirm.
Thanks,
Loic.
-----
> > > No problem. I can run the tests with a minimal effort on a 2x and a 8x
> > > IA32 xeon, and with SuSe 9.0; SLES 9; FC2. (and standard kernel or
> > > vanilla; standard glibc or recent one). Is this enough to get some
> > > conclusions?
>
> Here are some results with this new testcase. I've included my comments
> after each log.
>
> (*) Case 1:
> Config:
> 2xIA32 / FC2 / vanilla kernel 2.6.8.1 / vanilla glibc 2004/09/27
>
> Log:
> [root@nptl Autre]# ./test_schedrr 2 5
> main> Spawn alarm thread
> main> Spawn test driver thread
> alarm> Waiting that alarm is fired up
> alarm> Alarm activated
> testdrv> Starting 2 threads SCHED_RR with prio 5
> testdrv> The 2 SCHED_RR threads running at prio 5 have been created
> testdrv> Wait that all threads run...
> Thread 1: created but NOT STARTED
> Thread 2: started for 30.000022000 sec, sched. 48006154 times
> TIMED OUT
>
> Comment:
> This is the worst case ! 2 threads are spawned over a 2x box, and one
> of them does not execute...
>
>
>
> (*) Case 2:
> Config:
> 2xIA32 / FC2 / vanilla kernel 2.6.8.1 / glibc not modified
>
> Log:
> [root@nptl Autre]# ./test_schedrr 2 5
> main> Spawn alarm thread
> main> Spawn test driver thread
> alarm> Waiting that alarm is fired up
> alarm> Alarm activated
> testdrv> Starting 2 threads SCHED_RR with prio 5
> testdrv> The 2 SCHED_RR threads running at prio 5 have been created
> testdrv> Wait that all threads run...
> Thread 1: started for 29.999938000 sec, sched. 49504450 times
> Thread 2: created but NOT STARTED
> TIMED OUT
>
> Comment:
> Same result as the previous case -- the libc seems to have no
> influence here.
>
>
>
> (*) Case 3:
> Config:
> 2xIA32 / FC2 / Fedora kernel 2.6.5-1.358smp / glibc not modified
>
> Log:
> # ./test_schedrr 2 5
> main> Spawn alarm thread
> alarm> Waiting that alarm is fired up
> main> Spawn test driver thread
> alarm> Alarm activated
> testdrv> Starting 2 threads SCHED_RR with prio 5
> testdrv> The 2 SCHED_RR threads running at prio 5 have been created
> testdrv> Wait that all threads run...
> Thread 1: created but NOT STARTED
> Thread 2: started for 29.999449000 sec, sched. 9491932 times
> TIMED OUT
>
> Comment:
> Same behavior here but it required a few more iterations before the
> problem occured.
>
>
>
> (*) Case 4:
> Config:
> 2xIA32 / SLES9 / SuSe kernel 2.6.5-7.97-smp / glibc not modified
>
> Log:
> # ./test_schedrr 900 90
> main> Spawn alarm thread
> main> Spawn test driver thread
> alarm> Waiting that alarm is fired up
> alarm> Alarm activated
> testdrv> Starting 900 threads SCHED_RR with prio 90
> testdrv> The 900 SCHED_RR threads running at prio 90 have been created
> testdrv> Wait that all threads run...
> Thread 1: started for 30.000553000 sec, sched. 36012 times
> Thread 2: started for 30.000538000 sec, sched. 1 times
> Thread 3: started for 30.000507000 sec, sched. 35961 times
> Thread 4: started for 30.000488000 sec, sched. 1 times
> Thread 5: started for 30.000468000 sec, sched. 1 times
> ...
> Thread 141: created but NOT STARTED
> ...
> Thread 899: started for 29.973061000 sec, sched. 103348 times
> Thread 900: started for 29.973035000 sec, sched. 104301 times
> TIMED OUT
>
> Comment:
> The problem appears very less frequently with this configuration, but
> it still appears. It looks like most of the threads are scheduled only
> once, which is also a problem -- it could be worth modifying the
> testcase to report cases where the threads have been scheduled only
> once... What do you think?
>
>
>
> (*) Case 5:
> Config:
> 2xIA32 / SLES9 / vanilla kernel 2.6.8.1 / vanilla glibc 2004/09/27
>
> Log:
> nptl:/home1/thedoc/ts/Autre # ./test_schedrr 2 5
> main> Spawn alarm thread
> main> Spawn test driver thread
> alarm> Waiting that alarm is fired up
> alarm> Alarm activated
> testdrv> Starting 2 threads SCHED_RR with prio 5
> testdrv> The 2 SCHED_RR threads running at prio 5 have been created
> testdrv> Wait that all threads run...
> Thread 1: started for 29.999895000 sec, sched. 49357697 times
> Thread 2: created but NOT STARTED
> TIMED OUT
>
> Comment:
> Same result as with FC2. It looks like the distrib is not influent
> (good!)
>
>
>
> (*) Case 6:
> Config:
> 2xIA32 / SLES9 / vanilla kernel 2.6.8.1 / glibc not modified
>
> Log:
> nptl:/home1/thedoc/ts/Autre # ./test_schedrr 1000 90
> main> Spawn alarm thread
> main> Spawn test driver thread
> alarm> Waiting that alarm is fired up
> alarm> Alarm activated
> testdrv> Starting 1000 threads SCHED_RR with prio 90
> testdrv> The 1000 SCHED_RR threads running at prio 90 have been created
> testdrv> Wait that all threads run...
> PASSED
>
> Comment:
> I was unable to reproduce the problem in this configuration. But it
> would be interesting to see if the threads are scheduled only once, or
> if they all execute equally (only depending on their age).
>
>
>
> Best regards,
> Sebastien.
>
>
>
> -------------------------------
> Sebastien DECUGIS
> NPTL Test & Trace Project
> http://nptl.bullopensource.org/
>
> "You may fail if you try.
> You -will- fail if you don't."
>
>
> Liste de diffusion nptl
> Pour se désinscrire :
> mailto:nptl_request@bullopensource.org?subject=unsubscribe
>
--
--
// Sender address goes to /dev/null (!!)
// Use my 32/64 bits, ANSI C89, compliant email-address instead:
unsigned y[]=
{0,34432,26811,16721,41866,63119,61007,48155,26147,10986};
void x(z){putchar(z);}; unsigned t;
main(i){if(i<10){t=(y[i]*47560)%65521;x(t>>8);x(t&255);main(++i);}}
+++ GMX DSL Premiumtarife 3 Monate gratis* + WLAN-Router 0,- EUR* +++
Clevere DSL-Nutzer wechseln jetzt zu GMX: http://www.gmx.net/de/go/dsl
Liste de diffusion nptl
Pour se désinscrire : mailto:nptl_request@bullopensource.org?subject=unsubscribe