[tracecompass-dev] Towards "priority inversions"

[Matthew Khouzam <matthew.khouzam@xxxxxxxxxxxx>]

Hi all, I was analyzing the aspect of priority inversions and why we
want to trace it.

A reminder:

Let's say you have 3 threads. 
A is high priority
B is medium priority
C is low priority

A runs, then C runs, and takes a mutex, the B runs, A wants to run now,
but can't since it needs the mutex. So C is scheduled in instead of A. 

This means we need to track futexes and then see who holds one, if a
task asks for a locked futex, we need to check if it's priority is
higher than the thread. If the given thread is then not scheduled in,
but a lower priority thread is, we have an inversion. The inversion
starts then, and finishes when that task (A) is resumed.

THAT BEING SAID, what do people want to find out with a priority inversion view. I think it could be argued that they would want to find where their thread slowed down and why.

I propose a work around that is much simpler and in my opinion more robust. :)

They have an important thread. They want to isolate it and see its interactions. They also have an idea that it is being pre-empted by the wrong thread. 

Linux supported priority inheritance since the kernel v2.6 I think. [1]

What Linux cannot fix is people manually badly assigning priorities to their threads. A quick way to show all priority inversions is to track a given thread and show how long it's been pre-empted for any given point in time. An analysis like this would help locate regions of interest in the thread. Please understand, we may threads that last hours. Displaying everything in the priority view would be chaotic. Once all these intervals are shown, probably using segment based analyses which are awesome. We can then locate particularly egregious cases where we either wait often, a lot or both. and show these smaller cases that would be in the second to sub-second range in a priority inversion view.

So now, what is a priority inversion view? We show a thread and what pre-empts it. We have that! it's our critical path view, thanks Francis! We just need to add the thread priority into the tool tip. As the priority may escalate, we are better off not putting it in the column on the side.

Please tell me if you see use cases that are not covered by this.

To recap my use case is: user wants to find why her or his program is slowing down. 

Step 1- locate the showdown on the system level. 
Step 2- show the reason for the slowdown, including thread priorities.

This covers external slowdowns of course. This analysis cannot tell the user they are badly implementing their code.


[1] http://www.linuxquestions.org/questions/linux-software-2/how-is-priority-inversion-managed-in-linux-kernel-465222/