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] [day] [month] [year] [list]

Message-ID: <aAGdt7GftthwJ1+6@hu-mdtipton-lv.qualcomm.com>
Date: Thu, 17 Apr 2025 17:32:55 -0700
From: Mike Tipton <quic_mdtipton@...cinc.com>
To: "Aiqun(Maria) Yu" <quic_aiquny@...cinc.com>
CC: Georgi Djakov <djakov@...nel.org>, <linux-pm@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <quic_okukatla@...cinc.com>
Subject: Re: [PATCH] interconnect: Replace mutex with rt_mutex

On Thu, Apr 17, 2025 at 07:13:52PM +0800, Aiqun(Maria) Yu wrote:
> On 9/7/2022 10:59 PM, Mike Tipton wrote:
> > On Wed, Sep 07, 2022 at 10:35:26AM +0300, Georgi Djakov wrote:
> >> 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.
> > 
> > I can try to dig up some numbers, but mileage will vary tremendously of
> > course. Improvement is really only seen in certain high-concurrency
> > scenarios.
> 
> We need to revisit this thread because the issue has been reported again
> recently.
> Here is the data I can provide regarding the performance issue. Please
> check if it is sufficient for the commit message to understand the change.
> The CFS normal tasks holding the mutex lock were runnable for
> approximately 40ms in a busy load scenario, causing the RT task to wait
> for the mutex for about 40ms, which resulted in the RT task not being
> 'real-time' enough and causing janks. Changing the mutex to an RT mutex
> helped the caller of the interface, such as icc_set_bw, to ensure that
> RT tasks can deliver RT priority to the current RT mutex owner quickly,
> thereby improving performance in this scenario.

I'll post an updated and rebased version of this patch soon. In addition
to the display use cases, it was recently reported for certain other GPU
use cases as well.

> 
> > 
> > I'm not sure what an alternative, generic solution would be. We have
> > many clients requesting many different paths. Some are more
> > latency-sensitive and higher priority than others. If these use cases
> > overlap, then we're subject to these sorts of priority inversion issues.
> > Bumping the priority of all clients to match the highest priority one
> > isn't really possible.
> 
> Based on my understanding, rt_mutex is a good API to solve this type of
> issue.

I agree and still don't see any generic solution aside from this.