android_kernel_samsung_sm8650/fs/pstore
John Stultz 3ff04317e4 FROMGIT: pstore: Revert pmsg_lock back to a normal mutex
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.

After this change landed, it was reported that cases where the
mutex locking overhead was commonly adding on the order of 10s
of usecs delay had suddenly jumped to ~msec delay with rtmutex.

It seems the slight differences in the locks under this level
of contention causes the normal mutexes to utilize the spinning
optimizations, while the rtmutexes end up in the sleeping
slowpath (which allows additional threads to pile on trying
to take the lock).

In this case, it devolves to a worse case senerio where the lock
acquisition and scheduling overhead dominates, and each thread
is waiting on the order of ~ms to do ~us of work.

Obviously, having tons of threads all contending on a single
lock for logging is non-optimal, so the proper fix is probably
reworking pstore pmsg to have per-cpu buffers so we don't have
contention.

Additionally, Steven Rostedt has provided some furhter
optimizations for rtmutexes that improves the rtmutex spinning
path, but at least in my testing, I still see the test tripping
into the sleeping path on rtmutexes while utilizing the spinning
path with mutexes.

But in the short term, lets revert the change to the rt_mutex
and go back to normal mutexes to avoid a potentially major
performance regression. And we can work on optimizations to both
rtmutexes and finer-grained locking for pstore pmsg in the
future.

Cc: Wei Wang <wvw@google.com>
Cc: Midas Chien<midaschieh@google.com>
Cc: "Chunhui Li (李春辉)" <chunhui.li@mediatek.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Anton Vorontsov <anton@enomsg.org>
Cc: "Guilherme G. Piccoli" <gpiccoli@igalia.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: kernel-team@android.com
Fixes: 76d62f24db07 ("pstore: Switch pmsg_lock to an rt_mutex to avoid priority inversion")
Reported-by: "Chunhui Li (李春辉)" <chunhui.li@mediatek.com>
Signed-off-by: John Stultz <jstultz@google.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20230308204043.2061631-1-jstultz@google.com
Bug: 271041816
Bug: 272453930
(cherry picked from commit 5239a89b06d6b199f133bf0ffea421683187f257
 https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git for-next/pstore )
Change-Id: Iadf30bcbf5ba3895dd4af8c15c3a8aecf4301acb
Signed-off-by: John Stultz <jstultz@google.com>
2023-03-09 21:58:51 +00:00
..
blk.c pstore/blk: Use "%lu" to format unsigned long 2021-11-21 09:44:19 -08:00
ftrace.c pstore/ftrace: Allow immediate recording 2021-11-18 10:29:52 -08:00
inode.c pstore: Add priv field to pstore_record for backend specific use 2022-06-24 20:40:04 +02:00
internal.h pstore: Move kmsg_bytes default into Kconfig 2020-12-01 12:09:17 -08:00
Kconfig pstore: Make sure CONFIG_PSTORE_PMSG selects CONFIG_RT_MUTEXES 2022-12-31 13:33:08 +01:00
Makefile pstore/blk: Introduce backend for block devices 2020-05-30 10:34:03 -07:00
platform.c Revert "pstore: migrate to crypto acomp interface" 2022-09-30 08:16:06 -07:00
pmsg.c FROMGIT: pstore: Revert pmsg_lock back to a normal mutex 2023-03-09 21:58:51 +00:00
ram_core.c pstore: Avoid kcore oops by vmap()ing with VM_IOREMAP 2022-12-31 13:31:54 +01:00
ram.c ANDROID: pstore/ram: Add backward compatibility for ramoops reserved region 2023-02-22 20:23:47 +00:00
zone.c pstore/zone: Use GFP_ATOMIC to allocate zone buffer 2023-01-04 11:28:59 +01:00