Messages in this thread | | | From | John Stultz <> | Date | Mon, 6 Mar 2023 10:27:34 -0800 | Subject | Re: [PATCH v2] pstore: Revert pmsg_lock back to a normal mutex |
| |
On Sun, Mar 5, 2023 at 8:36 AM Steven Rostedt <rostedt@goodmis.org> wrote: > > On Sat, 4 Mar 2023 03:10:29 +0000 > John Stultz <jstultz@google.com> wrote: > > > This reverts commit 76d62f24db07f22ccf9bc18ca793c27d4ebef721. > > > > So while priority inversion on the pmsg_lock is an occasional > > problem that an rt_mutex would help with, in uses where logging > > is writing to pmsg heavily from multiple threads, the pmsg_lock > > can be heavily contended. > > > > Normal mutexes can do adaptive spinning, which keeps the > > contention overhead fairly low maybe adding on the order of 10s > > of us delay waiting, but the slowpath w/ rt_mutexes makes the > > blocked tasks sleep & wake. This makes matters worse when there > > is heavy contentention, as it just allows additional threads to > > run and line up to try to take the lock. > > That is incorrect. rt_mutexes have pretty much the same adaptive spinning > as normal mutexes. So that is *not* the reason for the difference in > performance, and should not be stated so in this change log.
Good point. Apologies, I was trying to describe the *behavior* being seen in the traces by switching between mutex and rt_mtuex, but I do see how it reads as a description of the capabilities of the primitive.
thanks -john
| |