On 04.09.2015 15:34, Thomas Gleixner wrote:
On Fri, 4 Sep 2015, Ioan-Adrian Ratiu wrote:
Hello
I wrote a C program to check jitter levels in userspace (source attached), ran
it on various kernels (3.14.19-rt9, 3.18.9-rt5 and 4.1.5-rt5) and on multiple
machines.
<snip>
At .412321, "Low-prio******"'s priority is raised by "High-prio******" again,
as if "High-prio******" is waiting for something, but then why was it woken up
before?
* did "Low-prio******" acquire the lock again? How could it manage this feat
since it is already in the unlock system call?
That looks like highprio is trying to acquire a kernel internal lock
held by lowprio. The only lock which can cause this is the futex
hashbucket lock.
Now, I can see why that happens in 3.14.19-rt9, 3.18.9-rt5, but
4.1.5-rt5 has a fix for that. Are you sure that you that this happens
on 4.1.5-rt5 as well?
It was a 4.1.3-rt3 build, sorry.
I will try the latest 4.1.5-rt5 and come back if this is still an issue.
Thank you,
Adrian
--
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
