I have a complex automation project with makes heavy use of real time prio threads working with external hardware connected by e.g. TCP/IP. IMHO most of my latencies simply come from the fact that there are multiple threads running on the same RT prio being scheduled FIFO. (poor design, yes, but that's what I want to fix) Expected response time is in low millsecond area, so no miroseconds juggling here. The process is running (alone, no other processes there) on one CPU of an i5 quad core (using 3.13.0-35 ubuntu 14.04) My first goal is to find out about the worst case latency: Is there a way I can find out how long (worst case) a RT thread being ready to run is just waiting to be dispatched? I tried /proc/pid/sched and was looking for se.statistics.wait_max but this was always 0. Going through the kernel sources I found out that these value (among many of the neighbors) is not calculated for real time threads (rt.c). Is there a reason for this? Is there another, maybe better way how I can achieve my goal? My second goal would be to identify the tasks (which ones?) consuming so much time (how much?) in this situation and thus causing the delay. Is there something built in to track down these bad guys? I think of something that keeps capturing the PIDs and exec time of all dispatched threads while a thread is waiting. If it turns out that it runs into worst case latency, the collected data could give a hint where to dig. On proc/pid/sched there is se.statistics.exec_max, some thread having a large number there can be a candidate, yes, but that is not necessarily causing my latency.. But I think more of a bad situation where a lot of tasks need to work at the same time bloating the run queue and thus causing the latency. I feel my solution is more "intelligent workload distribution" by identifying not so urgent work and shifting it to a later point in time. Thanks in advance jue -- 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
