[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <760fed2808aa46729eab9d0037d0904e@AcuMS.aculab.com>
Date: Wed, 7 Sep 2022 08:15:21 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Georgi Djakov' <djakov@...nel.org>,
Mike Tipton <quic_mdtipton@...cinc.com>
CC: "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"quic_okukatla@...cinc.com" <quic_okukatla@...cinc.com>
Subject: RE: [PATCH] interconnect: Replace mutex with rt_mutex
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@...cinc.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)
Powered by blists - more mailing lists