On Mon, Jun 04, 2018 at 11:48:07PM +0200, Henrik Austad wrote: > On Tue, Jun 05, 2018 at 12:30:47AM +0300, Ran Shalit wrote: > > On Tue, Jun 5, 2018 at 12:04 AM, Henrik Austad <henrik@xxxxxxxxx> wrote: [..] > > 1. Are all above suggestions valid also for "soft realtime", i.e. > > linux without rt patch, yet using rt threads priorities, mlock, etc ? > > Yes, this goes for all "time-sensitive" threads, avoid unbounded latencies > and uncertainties where you can. > > Steps to do (in no particular order, what is optimal for me may not be > optimal for you): > > - Do a (careful) analysis of your tasks priorities to make sure the most > important thread have the highest pri > - Use locks with priority inheritance > - Steer interrupts away from the core with the RT thread (if you have more > than 1 core) Note that this should be true for all of the irrelevant/secondary interrupts for your application. For those interrupts which are themselves part of your RT application, you'll want these delivered/affinitized to the same CPU as your RT task(s), lest you fall victim to interrupt and irqthread scheduling latencies on a housekeeping CPU. Julia -- 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
