[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [tracecompass-dev] Towards "priority inversions"
|
Hi
One other thing could be interesting for this. Processes could be
grouped by CPU and sorted by priority and their process states are shown
similar to the Control Flow view. The grouping could be done in the
Resources view since there is already grouping by CPU. The processes
would be children of the CPUs and sorted by priority. By showing the
processes by priority it's easier to find where a process with lower
priority was boosted to higher priority due to priority inversion.
Maybe it would be probably a good idea to not show all processes by
default but allow the user to select the processes of interest.
Bernd
On 02/09/2016 09:25 AM, Bernd Hufmann wrote:
Hi Matthew
Thanks for the assessment and the proposal. I think it will at great
value to Trace Compass once it can help users to locate and analyze
priority inversion.
/Bernd
On 01/29/2016 04:55 PM, Matthew Khouzam wrote:
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/
_______________________________________________
tracecompass-dev mailing list
tracecompass-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tracecompass-dev