RE: [PATCH] interconnect: Replace mutex with rt_mutex

[David Laight <David.Laight@ACULAB.COM>]

From: Georgi Djakov
> Sent: 07 September 2022 08:35
> 
> Hi Mike,
> 
> Thanks for the patch!
> 
> On 6.09.22 22:14, Mike Tipton wrote:
> > Replace mutex with rt_mutex to prevent priority inversion between
> > clients, which can cause unacceptable delays in some cases.
> 
> It would be nice if you have any numbers to share in the commit text.
> 
> > Signed-off-by: Mike Tipton <quic_mdtipton@quicinc.com>
> > ---
> >
> > We've run into a number of cases internally and from customers where
> > high priority, RT clients (typically display) become blocked for long
> > periods of time on lower priority, non-RT clients. Switching to rt_mutex
> > has proven to help performance in these cases.
> 
> I am wondering if avoiding the inversion on this specific lock is the right
> solution, as there could be other locks that may cause similar issues. Do we
> see similar issue with clocks for example or is it just with interconnects?

My thoughts exactly.

Although I've not tried to use the RT kernel I have tried to
get a highly threaded RT (audio) userspace application to
run reliable.

Userspace only has sleep locks so you get all the priority
inversion problems.
This big problems arise with a highly contended lock that
is never held for very long - a prime candidate for spin lock.
If a process is even interrupted while holding the lock the
entire application stops.
The only way I found to avoid this is to replace all the locking
with atomic operations.

I can't see why the RT kernel doesn't have exactly the same issues.
Given how long a process switch takes I really suspect that most
spinlocks should remain spinlocks.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)