Re: 2.6.14-rt1

[Carlos Antunes <cmantunes@gmail.com>]

On 11/2/05, Florian Schmidt <mista.tapas@gmx.net> wrote:
> On Tue, 1 Nov 2005 23:05:09 -0500
> Carlos Antunes <cmantunes@gmail.com> 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
>

That's interesting. Are you running a fairly recent pthread lib?

>
> 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.
>

Did you run that with SCHED_FIFO or SCHED_OTHER? If it was with
SCHED_FIFO, it was a pretty good result. But maybe your machine is
just very fast. What CPU is that? DId you use 2.6.14-rt2 or some other
version?

>
> 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.
>

Yes, they are supposed to act differently. In particular, my
understanding of realtime scheduling suggests SCHED_FIFO is supposed
to provide better (meaning lower) wakeup latency.

Thanks for tryting this out. Although I'm still puzzled at the low
number of threads you were able to create.

Carlos

--
"We hold [...] that all men are created equal; that they are
endowed [...] with certain inalienable rights; that among
these are life, liberty, and the pursuit of happiness"
        -- Thomas Jefferson
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/