[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[nptl] New results
> > 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