On Tue, Aug 17, 2010 at 11:24 AM, Manikandan Ramachandran <crmanik@xxxxxxxxx> wrote: <SNIP> > > Thanks David & Mark for your valuable input! > > I'm not expecting RT kernel to be real fast. However I expect latency > of higher priority task to be less in RT kernel. I'll run the tests > that you have suggested and see if there is any inherent issue with my > system. > It is not that the delay of a high priority task is less in the rt kernel. It's more that it meets a maximum latency number more often. It's more _dependable_ in meeting a known latency value than the standard kernel. > One more query, with RT patch is it possible for higher priority task > to preempt a lower priority IRQ thread [For eg, IDE] ? If so when does > that happen, during next timer interrupt [Assuming IRQ thread uses > whole schedule slot and doesn't yield between]? Yes, it is possible for higher priorities to interrupt low priorities. In a __properly__ functioning system higher priority should always trump lower priority. The higher runs and then the lower picks up where it left off. In your question it seems to me you are assuming a device or it's software is not 'real time compliant' which has certainly been the case a few times over the years. If a lower priority device won't yield - maybe it's in some tight loop that doesn't pay attention to the kernel? - then that software needs to be fixed or the system won't produce predictable latencies. Over the years this has become much less an issue but I'm not sure anything can be guaranteed without testing. Again, I'm not a programmer but I've used these kernels for years so I speak from sort of a practical user POV and not necessarily the most accurate software technical POV. (I'm a hardware guy) -- 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
