On Tue, Jun 5, 2018 at 1:02 AM, Julia Cartwright <julia@xxxxxx> wrote: > 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 Thank you for the useful comments, Julia, Henrik. I have a lot of information to digest now. Yet, I would please like to ask about the data transfer of data for the other thread which is responsible for file write: I want to use std::queue for transferring data from the high priority RT thread to the lower priority RT thread responsible for file write (the lower priority thread should yet be *RT* thread too, just with lower priority, right ?). I don't see that documentation in c++ states if std::queue is blocking on mutex or not, yet I guess that push should not block. Does it sound reasonable assumption ? Thank you very much, Ran -- 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
