On Thu, May 7, 2009 at 6:31 PM, David L <idht4n@xxxxxxxxx> wrote: > On Wed, May 6, 2009 at 10:29 PM, Sujit Karataparambil wrote: > I'm not sure I understand this question, but I'll try to > answer it anyway. There is one process with a handful > of SCHED_FIFO-scheduled threads. The highest > priority one blocks on a read from a driver that interfaces > with an FPGA and wakes up every ~950 microseconds. > It seems to consume about 250 microseconds per > msec using the mainline kernel. That thread can tolerate > frequent delays of a few msec with a rare delay of up to > about 7 msec... after that, we lose track of the RF > signals we're tracking. Why cannot you have mutiple threads for SCHED_FIFO? Say you could have one process with the Highest Priority alone on an low priority process. With the other matching process as per their priority requirements? Using shared memory. This requires a lot of R&D in terms of sleep issued on the application? > > There are a few lower priority threads that do some > processing of the data demodulated by the highest > priority thread. Those have relatively soft real-time > requirements. Earlier I said they needed a second > of CPU time every few seconds. Really, it's probably > more like a second every 5 seconds. I think this might not be a problem? After the First Step is taken? > >> Whether it can be changed to get the current >> application running? > I don't think so, but I haven't exhaustively tried different > priorities. I've just tried a few that seem reasonable. I know > it doesn't work with the same priority levels for which it works > almost perfectly without the real-time patches. And I know it > doesn't work after lowering all of the priorities such that only > one is above 50. The symptom is 2x higher CPU loading > relative to the non-real-time-patched kernel. Is the Processor supporting SMP? or Does it have SMP Capabilities? >> Also What is the Specific part to PPC32 and PPC64? > PPC32 (specifically, an MPC5200) http://kerneltrap.org/Linux/Balancing_Real_Time_Threads > Without the real-time patch applied, I used top to watch the CPU > consumption per thread. I also used the kernel sched_switch > tracing tool and the application monitors its own CPU usage > using clock_gettime with a clock initialized by pthread_getcpuclockid. > With the real-time patch applied, top doesn't run the way I usually > run it because the CPU is starved. I guess I could run top at a > high priority, but I haven't tried that. But the kernel trace I showed > with the original email shows what is running when, and it shows > that the CPU is never idle. http://kerneltrap.org/Linux/Balancing_Real_Time_Threads > I guess it depends on the exact definition. The thread that > interacts with the FPGA needs to read the FGPA data typically > within say 2-3 msec with a rare excursion to ~7 msec. > The mainline kernel does this under most conditions but it seems > like it just barely makes it and some small changes to the system can > cause us to miss those deadlines. Could the data be preread or part of it during boot/initialization. -- -- 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
