Recently, we resolved a latency spike issue caused by concurrently running bpftrace processes. The root cause was high contention on the ftrace_lock due to optimistic spinning. We can optimize this by disabling optimistic spinning for ftrace_lock.
While semaphores may present similar challenges, I'm not currently aware of specific instances that exhibit this exact issue. Should we encounter problematic semaphores in production workloads, we can address them at that time. PATCH #1: introduce slow_mutex_[un]lock to disable optimistic spinning PATCH #2: add variant for rtmutex PATCH #3: disable optimistic spinning for ftrace_lock v1->v2: - add slow_mutex_[un]lock (Steven) - add variant for rtmutex (Waiman) - revise commit log for clarity and accuracy (Waiman, Peter) - note that semaphores may present similar challenges (David) RFC v1: https://lore.kernel.org/bpf/[email protected]/ Yafang Shao (3): locking/mutex: Add slow path variants for lock/unlock locking/rtmutex: Add slow path variants for lock/unlock ftrace: Disable optimistic spinning for ftrace_lock include/linux/mutex.h | 4 ++ include/linux/rtmutex.h | 3 + kernel/locking/mutex.c | 41 +++++++++++--- kernel/locking/rtmutex.c | 37 +++++++----- kernel/locking/rtmutex_api.c | 47 +++++++++++++--- kernel/trace/ftrace.c | 106 +++++++++++++++++------------------ 6 files changed, 157 insertions(+), 81 deletions(-) -- 2.47.3
