The Linux Kernel Mailing List
 help / color / mirror / Atom feed
* [RFC PATCH 0/1] binder: switch alloc->mutex back to spinlock
@ 2026-08-05 15:27 Bo Zhang
  2026-08-05 15:27 ` [RFC PATCH 1/1] " Bo Zhang
  2026-08-06  9:01 ` [RFC PATCH 0/1] " Alice Ryhl
  0 siblings, 2 replies; 4+ messages in thread
From: Bo Zhang @ 2026-08-05 15:27 UTC (permalink / raw)
  To: gregkh, cmllamas, aliceryhl
  Cc: arve, tkjos, christian, surenb, baohua, zhanghongru06,
	linux-kernel, Bo Zhang

Hi,

This patch switches the binder_alloc mutex back to a spinlock to reduce
transaction latency.

Background:

Commit 7710e2cca32e ("binder: switch alloc->mutex to spinlock_t")
originally converted the mutex to a spinlock for performance. It was
later reverted by commit 8b52c7261e04 in preparation for commit
d1716b4b78fb ("binder: concurrent page installation"), which states:

  "zap_page_range_single() is called under the alloc->mutex to avoid
   racing with the shrinker."

Analysis:

After inspection, holding the lock across zap_vma_range() in the shrinker
path is unnecessary. The page installation side does NOT hold alloc->mutex,
so the mutex provides no mutual exclusion between install and zap. The 
actual synchronization is guaranteed at the PTE lock level:

  1. vm_insert_page() acquires the PTE lock to set the PTE entry.
  2. zap_vma_range() acquires the PTE lock to clear the PTE entry.
  3. On race conditions, the install path calls binder_page_lookup
     which uses get_user_pages_remote() to atomically pin the page
     under PTE lock, preventing use-after-free regardless of zap timing.

The alloc lock only needs to protect buffer metadata (rb-trees, pages
array, LRU list operations), all of which are non-sleeping and complete
before zap_vma_range() is called.

By moving spin_unlock() before zap_vma_range() in the shrinker path, we
can safely convert back to a spinlock.

Performance (binderThroughputTest, Qualcomm SM8850, 2 workers, 10 runs):

                    mutex               spinlock
  throughput:    27k-59k iter/s       79k-84k iter/s  (~80% improvement)
  average:       0.031-0.068ms        0.022-0.023ms   (~45% reduction)
  P99:           0.088-0.148ms        0.050-0.062ms   (~55% reduction)
  variance:      high (2x spread)     low (stable)

The spinlock eliminates priority inversion where low-priority tasks
holding the mutex sleep, blocking high-priority binder transactions.

Looking forward to feedback on this analysis.

Bo Zhang (1):
  binder: switch alloc->mutex back to spinlock

 drivers/android/binder_alloc.c | 36 +++++++++++++++++-----------------
 drivers/android/binder_alloc.h |  8 ++++----
 2 files changed, 22 insertions(+), 22 deletions(-)

-- 
2.34.1

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2026-08-06 14:23 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-08-05 15:27 [RFC PATCH 0/1] binder: switch alloc->mutex back to spinlock Bo Zhang
2026-08-05 15:27 ` [RFC PATCH 1/1] " Bo Zhang
2026-08-06  9:01 ` [RFC PATCH 0/1] " Alice Ryhl
2026-08-06 14:23   ` Bo Zhang

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox