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
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
