On Thu, May 7, 2009 at 4:48 AM, Nivedita Singhvi <niv@xxxxxxxxxx> wrote: > 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). Could you be more specific on what part of the Real Time Code is this priority being set? Whether it can be changed to get the current application running? Also What is the Specific part to PPC32 and PPC64? > >> 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(?). Could you tell us some tool that can be used to measure the time taken other than the time function. Also how much of the time is required by the SCHED_FIFO? > >> 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... Could you tell whether it is HARD real time or Soft Real Time? > > 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 > -- -- Sujit K M -- 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
