linux-kernel - RE: [PATCH] interconnect: Replace mutex with rt

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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)