Re: idle task starvation with rt patch

[Nivedita Singhvi <niv@us.ibm.com>]

David L wrote:

> In mainline, we have our receiver application schedules about
> 6 threads, all with SCHED_FIFO priority between about 65 and 97.
> After applying the real-time patch, I noticed some IRQ handling
> processes that appeared to have a real-time priority of about 50.
> So I tried adjusting our application's priority to have only one thread
> with priority higher than 50 (the one with the real-time requirements
> that nomincally uses about 250 usec per msec of CPU).

Right - the bulk of the interrupt overhead (including
processing of softirqs etc) would not occur (or rather,
would not be allowed to preempt your SCHED_FIFO task at 
higher priority).

> Our receiver process which tracks RF signals based on the
> information from an FPGA that provides baseband accumulated
> samples at about 1000 times per second.  It has some lower
> priority SCHED_FIFO threads that have relatively loose timing
> constraints but do need about a second of CPU time every few
> seconds to prevent a queue overflow that causes the process
> to assert and crash by design.

A second of CPU time every few seconds sounds like a
lot, actually - even if lower priority, it still sounds
like it's a must-happen, and you might need to bump up
its priority(?).

> The priorities all seem to be set right... without the real-time
> patches, it seems that the kernel isn't real-time enough to
> meet our timing requirements in some cases.  With the real-time
> patches, the CPU loading for the identical process goes from
> about 50% to about 100%.  I'm wondering why there is such
> a dramatic difference in CPU usage.

You might need to instrument it further or use ftrace
to figure out what's happening. RT is slower to process
incoming interrupts (kernel threads vs softirqs) so it
might be a factor - do you use affinity to pin threads
and/or interrupts? You might be able to play with that
to perhaps avoid the problem. It should not behave this
differently, but I could be wrong...

thanks,
Nivedita