summaryrefslogtreecommitdiffhomepage
path: root/pkg/sentry/fs/lock/BUILD
diff options
context:
space:
mode:
authorAyush Ranjan <ayushranjan@google.com>2021-03-29 10:50:40 -0700
committergVisor bot <gvisor-bot@google.com>2021-03-29 10:52:19 -0700
commitda6ddd1df8ef9684d548ec17e7f0e51f5427211b (patch)
treed7f47b5468c6b19e9378c2d4c4e4b6abae692979 /pkg/sentry/fs/lock/BUILD
parentfbec65fc3f21773cbec3db4aadf27b85e8859448 (diff)
[perf] Reduce contention in ptrace.threadPool.lookupOrCreate().
lookupOrCreate is called from subprocess.switchToApp() and subprocess.syscall(). lookupOrCreate() looks for a thread already created for the current TID. If a thread exists (common case), it returns immediately. Otherwise it creates a new one. This change switches to using a sync.RWMutex. The initial thread existence lookup is now done only with the read lock. So multiple successful lookups can occur concurrently. Only when a new thread is created will it acquire the lock for writing and update the map (which is not the common case). Discovered in mutex profiles from the various ptrace benchmarks. Example: https://gvisor.dev/profile/gvisor-buildkite/fd14bfad-b30f-44dc-859b-80ebac50beb4/843827db-da50-4dc9-a2ea-ecf734dde2d5/tmp/profile/ptrace/BenchmarkFio/operation.write/blockSize.4K/filesystem.tmpfs/benchmarks/fio/mutex.pprof/flamegraph PiperOrigin-RevId: 365612094
Diffstat (limited to 'pkg/sentry/fs/lock/BUILD')
0 files changed, 0 insertions, 0 deletions