> As I understand it, if you are doing your processing via interrupts, the > your latency to start processing interrupts will increase on average with > the PREEMPT_RT patch. There is additional scheduling overhead involved, and > as Sven pointed out, if you don't bump the prio of the interrupt you care > about, you can see MUCH higher latencies. > > The PREEMPT_RT patch adds things like the rt-mutex replacement of most > spinlocks, which adds preemption points and enable Priority Inheritance > within the kernel, but this is all geared towards enable real-time > applications. If you just want fast OS processing of interrupts, then > mainline provides you with a nice non-preemptible kernel side interrupt > implementation that won't be affected by things like applications :-) Thank you for this clarification. This really made me think. In mainline kernel, my interrupt will not be affected by other processes. But, it can be affected by other interrupts in the system, right? So, I still gain something from rt patch where I can scale down the priority of other interrupts so that they don't come in the way of my 1 ms interrupt. Now, if I got it correct, what I will have to see is whether this advantage outweighs the disadvantage of context switching delays. A quick search showed me http://choices.cs.uiuc.edu/ExpCS07.pdf. In page 25 they have listed time for context switches and interrupts. Those figures are rather dismal (~few milli seconds). Can someone familiar with ARM here tell me whether these numbers can be trusted? From the rt wiki I see that, on ARM, worst case latency is less than 300us. I will anyway repeat the tests that we did so far and will post the results again. @Sven: Just saw your reply. Thank you for the caution about nested PICs. I will check this also while repeating the tests. > Please slap me if I've misrepresented PREEMPT_RT somehow. (I'm sure no > invitation is actually required ;-) Since no one has done this so far, I trust you :) > > > -- > Darren Hart > IBM Linux Technology Center > Real-Time Linux Team > -- 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
