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? Thanks, tglx -- 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
