Re: 2.6.14-rt1

From: Florian Schmidt
Date: Wed Nov 02 2005 - 04:53:34 EST

On Tue, 1 Nov 2005 23:05:09 -0500
Carlos Antunes <cmantunes@xxxxxxxxx> wrote:

> Here's the thing:
> http://www.nowthor.com/OpenPBX/timing.c
>
> Let me know what kind of results you get.

Hi,

running the code i simply get:

~$ ./timing
Failed to create thread # 382
Failed to create thread # 383
Failed to create thread # 384
Failed to create thread # 385
Failed to create thread # 386
Failed to create thread # 387
..
Failed to create thread # 498
Failed to create thread # 499

and then

Segmentation fault

Probably caused by not handling that some threads didn't get created. I
reduced the number down to 300:

~$ ./timing
Histogram
Delay(ms) Count
0 300000
1 0
2 0
3 0
4 0
5 0
6 0
7 0
8 0
9 0
10 0
11 0
12 0
13 0
14 0
15 0
16 0
17 0
18 0
19 0
20 0
Num threads = 300
Total sleeps = 300000
Min error = 0.014 ms
Max error = 0.133 ms

What would you expect to see? BTW: cpu load stayed moderately small with
this setting here.

As a sidenote: Of course the scheduling works completely different with
hundreds of threads running SCHED_FIFO at the same priority than with
hundreds of threads running SCHED_OTHER. SCHED_OTHER threads can preempt
each other when the dynamic priority changes. SCHED_FIFO threads OTOH
just sit and wait until they get to run, not preempting other SCHED_FIFO
threads of the same priority. So basically each SCHED_FIFO thread waits
until all others have run.

Dunno, if that would make a difference in this case though..

Flo

--
Palimm Palimm!
http://tapas.affenbande.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/