Realtime-preempt performs worse for many threads?

[Carlos Antunes <cmantunes@gmail.com>]

Hi!

I've been developing some code for the OpenPBX project
(http://www.openpbx.org) and wrote a program to test how the system,
responds when hundreds of threads are spawned. These threads run at
high priority (SCHED_FIFO) and use clock_nanocleep with absolute
timeouts on a 20ms loop cycle.

With the stock 2.6.14 kernel, I get latencies in the order of several
milliseconds (but less than 20ms) when running 1250 threads
simultaneously. However, when I switch to a kernel patched with
realtime-preempt latency increases to several hundred milliseconds in
many cases.

When I only only spawn 10 or so threads, realtime-preempt gives me
latencies of less than 1ms while the stock kernel still gives me a few
milliseconds. However, when the number of threads sleeping on
clock_nanosleep increases to several hundred, things just break.

Should I assume that realtime-preempt at this time is not ready to
deal with hundreds of realtime threads sleeping most of the time on
clock_nanosleep?

Any ideas on how to maybe debug this and see if there is some kind of problem?

Thanks!

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