mirror of https://github.com/golang/go.git
12 Commits
| Author | SHA1 | Message | Date |
|---|---|---|---|
Michael Anthony Knyszek
|
7bad61554e |
runtime: write much more direct test for semaphore waiter scalability
This test originally existed as two tests in test/locklinear.go, but this checked against actual locks and was flaky. The test was checking a property of a deep part of the runtime but from a much higher level, and it's easy for nondeterminism due to scheduling to completely mess that up, especially on an oversubscribed system. That test was then moved to the sync package with a more rigorous testing methodology, but it could still flake pretty easily. Finally, this CL makes semtable more testable, exports it in export_test.go, then writes a very direct scalability test for exactly the situation the original test described. As far as I can tell, this is much, much more stable, because it's single-threaded and is just checking exactly the algorithm we need to check. Don't bother trying to bring in a test that checks for O(log n) behavior on the other kind of iteration. It'll be perpetually flaky because the underlying data structure is a treap, so it's only _expected_ to be O(log n), but it's very easy for it to get unlucky without a large number of iterations that's too much for a simple test. Fixes #53381. Change-Id: Ia1cd2d2b0e36d552d5a8ae137077260a16016602 Reviewed-on: https://go-review.googlesource.com/c/go/+/412875 Reviewed-by: Michael Pratt <mpratt@google.com> |
|
|
Michael Anthony Knyszek
|
56bc3098f4 |
sync: improve linearity test robustness
This change improves the robustness of the locklinear test in the following ways: * It removes allocations from the timing, which may be very variable if we're unlucky. * It ensures that goroutines are properly cleaned up before the test function returns, reducing the chance that they bleed into repeat attempts. It also stops timing before this cleanup. Fixes #32986. Change-Id: I3a8096e6922f23d899ad602e2845bdfc639ed742 Reviewed-on: https://go-review.googlesource.com/c/go/+/409894 Reviewed-by: Michael Pratt <mpratt@google.com> |
|
|
Michael Anthony Knyszek
|
1fe2810f9c |
sync: move lock linearity test and treat it like a performance test
This change moves test/locklinear.go into the sync package tests, and adds a bit of infrastructure since there are other linearity-checking tests that could benefit from it too. This infrastructure is also different than what test/locklinear.go does: instead of trying really hard to get at least one success, we instead treat this like a performance test and look for a significant difference via a t-test. This makes the methodology behind the tests more rigorous, and should reduce flakiness as transient noise should produce an insignificant result. A follow-up CL does more to make these tests even more robust. For #32986. Change-Id: I408c5f643962b70ea708930edb4ac9df1c6123ce Reviewed-on: https://go-review.googlesource.com/c/go/+/411396 Reviewed-by: Michael Pratt <mpratt@google.com> |
|
Russ Cox
|
645d07819b |
sync: add Mutex.TryLock, RWMutex.TryLock, RWMutex.TryRLock
Use of these functions is almost (but not) always a bad idea. Very rarely they are necessary, and third-party implementations (using a mutex and an atomic word, say) cannot integrate as well with the race detector as implmentations in package sync itself. Fixes #45435. Change-Id: I0128ca48ef5e0a3b09c913f0f3a7ee5c56388000 Reviewed-on: https://go-review.googlesource.com/c/go/+/319769 Trust: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> |
|
Gaurav Singh
|
5a18e0b58c |
sync: fix goroutine leak for when TestMutexFairness times out
If the timeout triggers before writing to the done channel, the
goroutine will be blocked waiting for a corresponding read that’s
no longer existent, thus a goroutine leak. This change fixes that by
using a buffered channel instead.
Change-Id: I9cf4067a58bc5a729ab31e4426edd78bd359e8e0
GitHub-Last-Rev:
|
|
Carlo Alberto Ferraris
|
4c3f26076b |
sync: allow inlining the Mutex.Unlock fast path
Make use of the newly-enabled limited midstack inlining. Similar changes will be done in followup CLs. name old time/op new time/op delta MutexUncontended 19.3ns ± 1% 18.9ns ± 0% -1.92% (p=0.000 n=20+19) MutexUncontended-4 5.24ns ± 0% 4.75ns ± 1% -9.25% (p=0.000 n=20+20) MutexUncontended-16 2.10ns ± 0% 2.05ns ± 0% -2.38% (p=0.000 n=15+19) Mutex 19.6ns ± 0% 19.3ns ± 1% -1.92% (p=0.000 n=20+17) Mutex-4 54.6ns ± 5% 52.4ns ± 4% -4.09% (p=0.000 n=20+20) Mutex-16 133ns ± 5% 139ns ± 2% +4.23% (p=0.000 n=20+16) MutexSlack 33.4ns ± 2% 18.9ns ± 1% -43.56% (p=0.000 n=19+20) MutexSlack-4 206ns ± 5% 225ns ± 8% +9.12% (p=0.000 n=20+18) MutexSlack-16 89.4ns ± 1% 98.4ns ± 1% +10.10% (p=0.000 n=18+17) MutexWork 60.5ns ± 0% 58.2ns ± 3% -3.75% (p=0.000 n=12+20) MutexWork-4 105ns ± 5% 103ns ± 7% -1.68% (p=0.007 n=20+20) MutexWork-16 157ns ± 1% 163ns ± 2% +3.90% (p=0.000 n=18+18) MutexWorkSlack 70.2ns ± 5% 57.7ns ± 1% -17.81% (p=0.000 n=19+20) MutexWorkSlack-4 277ns ±13% 276ns ±13% ~ (p=0.682 n=20+19) MutexWorkSlack-16 156ns ± 0% 147ns ± 0% -5.62% (p=0.000 n=16+14) MutexNoSpin 966ns ± 0% 968ns ± 0% +0.11% (p=0.029 n=15+20) MutexNoSpin-4 269ns ± 4% 270ns ± 2% ~ (p=0.807 n=20+19) MutexNoSpin-16 122ns ± 0% 120ns ± 4% -1.63% (p=0.000 n=19+19) MutexSpin 3.13µs ± 0% 3.13µs ± 1% +0.16% (p=0.004 n=18+20) MutexSpin-4 826ns ± 1% 832ns ± 2% +0.74% (p=0.000 n=19+16) MutexSpin-16 397ns ± 1% 395ns ± 0% -0.50% (p=0.000 n=19+17) RWMutexUncontended 71.4ns ± 0% 69.5ns ± 0% -2.72% (p=0.000 n=16+20) RWMutexUncontended-4 18.4ns ± 4% 17.5ns ± 0% -4.92% (p=0.000 n=20+18) RWMutexUncontended-16 8.01ns ± 0% 7.92ns ± 0% -1.15% (p=0.000 n=18+18) RWMutexWrite100 24.9ns ± 0% 24.9ns ± 1% ~ (p=0.099 n=19+20) RWMutexWrite100-4 46.5ns ± 3% 46.2ns ± 4% ~ (p=0.253 n=17+19) RWMutexWrite100-16 68.9ns ± 3% 69.9ns ± 5% +1.46% (p=0.012 n=18+20) RWMutexWrite10 27.1ns ± 0% 27.0ns ± 2% ~ (p=0.128 n=17+20) RWMutexWrite10-4 34.8ns ± 1% 34.7ns ± 2% ~ (p=0.180 n=20+18) RWMutexWrite10-16 37.5ns ± 2% 37.2ns ± 4% -0.89% (p=0.023 n=20+20) RWMutexWorkWrite100 164ns ± 0% 164ns ± 0% ~ (p=0.106 n=12+20) RWMutexWorkWrite100-4 186ns ± 3% 193ns ± 3% +3.46% (p=0.000 n=20+20) RWMutexWorkWrite100-16 204ns ± 2% 210ns ± 3% +2.96% (p=0.000 n=18+20) RWMutexWorkWrite10 153ns ± 0% 153ns ± 0% -0.20% (p=0.017 n=20+19) RWMutexWorkWrite10-4 179ns ± 1% 178ns ± 2% ~ (p=0.215 n=19+20) RWMutexWorkWrite10-16 191ns ± 1% 192ns ± 2% ~ (p=0.166 n=15+19) linux/amd64 bin/go 14630572 (previous commit 14605947, +24625/+0.17%) Change-Id: I3f9d1765801fe0b8deb1bc2728b8bba8a7508e23 Reviewed-on: https://go-review.googlesource.com/c/go/+/148958 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> |
|
Rhys Hiltner
|
f72196647e |
sync: throw, not panic, for unlock of unlocked mutex
This was originally done in https://golang.org/cl/31359 but partially undone (apparently unintentionally) in https://golang.org/cl/34310 Fix it, and update tests to ensure the error is unrecoverable. Fixes #23039 Change-Id: I923ebd613a05e67d8acce77f4a68c64c8574faa6 Reviewed-on: https://go-review.googlesource.com/82656 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Dmitry Vyukov <dvyukov@google.com> |
|
Dmitry Vyukov
|
0556e26273 |
sync: make Mutex more fair
Add new starvation mode for Mutex. In starvation mode ownership is directly handed off from unlocking goroutine to the next waiter. New arriving goroutines don't compete for ownership. Unfair wait time is now limited to 1ms. Also fix a long standing bug that goroutines were requeued at the tail of the wait queue. That lead to even more unfair acquisition times with multiple waiters. Performance of normal mode is not considerably affected. Fixes #13086 On the provided in the issue lockskew program: done in 1.207853ms done in 1.177451ms done in 1.184168ms done in 1.198633ms done in 1.185797ms done in 1.182502ms done in 1.316485ms done in 1.211611ms done in 1.182418ms name old time/op new time/op delta MutexUncontended-48 0.65ns ± 0% 0.65ns ± 1% ~ (p=0.087 n=10+10) Mutex-48 112ns ± 1% 114ns ± 1% +1.69% (p=0.000 n=10+10) MutexSlack-48 113ns ± 0% 87ns ± 1% -22.65% (p=0.000 n=8+10) MutexWork-48 149ns ± 0% 145ns ± 0% -2.48% (p=0.000 n=9+10) MutexWorkSlack-48 149ns ± 0% 122ns ± 3% -18.26% (p=0.000 n=6+10) MutexNoSpin-48 103ns ± 4% 105ns ± 3% ~ (p=0.089 n=10+10) MutexSpin-48 490ns ± 4% 515ns ± 6% +5.08% (p=0.006 n=10+10) Cond32-48 13.4µs ± 6% 13.1µs ± 5% -2.75% (p=0.023 n=10+10) RWMutexWrite100-48 53.2ns ± 3% 41.2ns ± 3% -22.57% (p=0.000 n=10+10) RWMutexWrite10-48 45.9ns ± 2% 43.9ns ± 2% -4.38% (p=0.000 n=10+10) RWMutexWorkWrite100-48 122ns ± 2% 134ns ± 1% +9.92% (p=0.000 n=10+10) RWMutexWorkWrite10-48 206ns ± 1% 188ns ± 1% -8.52% (p=0.000 n=8+10) Cond32-24 12.1µs ± 3% 12.4µs ± 3% +1.98% (p=0.043 n=10+9) MutexUncontended-24 0.74ns ± 1% 0.75ns ± 1% ~ (p=0.650 n=10+10) Mutex-24 122ns ± 2% 124ns ± 1% +1.31% (p=0.007 n=10+10) MutexSlack-24 96.9ns ± 2% 102.8ns ± 2% +6.11% (p=0.000 n=10+10) MutexWork-24 146ns ± 1% 135ns ± 2% -7.70% (p=0.000 n=10+9) MutexWorkSlack-24 135ns ± 1% 128ns ± 2% -5.01% (p=0.000 n=10+9) MutexNoSpin-24 114ns ± 3% 110ns ± 4% -3.84% (p=0.000 n=10+10) MutexSpin-24 482ns ± 4% 475ns ± 8% ~ (p=0.286 n=10+10) RWMutexWrite100-24 43.0ns ± 3% 43.1ns ± 2% ~ (p=0.956 n=10+10) RWMutexWrite10-24 43.4ns ± 1% 43.2ns ± 1% ~ (p=0.085 n=10+9) RWMutexWorkWrite100-24 130ns ± 3% 131ns ± 3% ~ (p=0.747 n=10+10) RWMutexWorkWrite10-24 191ns ± 1% 192ns ± 1% ~ (p=0.210 n=10+10) Cond32-12 11.5µs ± 2% 11.7µs ± 2% +1.98% (p=0.002 n=10+10) MutexUncontended-12 1.48ns ± 0% 1.50ns ± 1% +1.08% (p=0.004 n=10+10) Mutex-12 141ns ± 1% 143ns ± 1% +1.63% (p=0.000 n=10+10) MutexSlack-12 121ns ± 0% 119ns ± 0% -1.65% (p=0.001 n=8+9) MutexWork-12 141ns ± 2% 150ns ± 3% +6.36% (p=0.000 n=9+10) MutexWorkSlack-12 131ns ± 0% 138ns ± 0% +5.73% (p=0.000 n=9+10) MutexNoSpin-12 87.0ns ± 1% 83.7ns ± 1% -3.80% (p=0.000 n=10+10) MutexSpin-12 364ns ± 1% 377ns ± 1% +3.77% (p=0.000 n=10+10) RWMutexWrite100-12 42.8ns ± 1% 43.9ns ± 1% +2.41% (p=0.000 n=8+10) RWMutexWrite10-12 39.8ns ± 4% 39.3ns ± 1% ~ (p=0.433 n=10+9) RWMutexWorkWrite100-12 131ns ± 1% 131ns ± 0% ~ (p=0.591 n=10+9) RWMutexWorkWrite10-12 173ns ± 1% 174ns ± 0% ~ (p=0.059 n=10+8) Cond32-6 10.9µs ± 2% 10.9µs ± 2% ~ (p=0.739 n=10+10) MutexUncontended-6 2.97ns ± 0% 2.97ns ± 0% ~ (all samples are equal) Mutex-6 122ns ± 6% 122ns ± 2% ~ (p=0.668 n=10+10) MutexSlack-6 149ns ± 3% 142ns ± 3% -4.63% (p=0.000 n=10+10) MutexWork-6 136ns ± 3% 140ns ± 5% ~ (p=0.077 n=10+10) MutexWorkSlack-6 152ns ± 0% 138ns ± 2% -9.21% (p=0.000 n=6+10) MutexNoSpin-6 150ns ± 1% 152ns ± 0% +1.50% (p=0.000 n=8+10) MutexSpin-6 726ns ± 0% 730ns ± 1% ~ (p=0.069 n=10+10) RWMutexWrite100-6 40.6ns ± 1% 40.9ns ± 1% +0.91% (p=0.001 n=8+10) RWMutexWrite10-6 37.1ns ± 0% 37.0ns ± 1% ~ (p=0.386 n=9+10) RWMutexWorkWrite100-6 133ns ± 1% 134ns ± 1% +1.01% (p=0.005 n=9+10) RWMutexWorkWrite10-6 152ns ± 0% 152ns ± 0% ~ (all samples are equal) Cond32-2 7.86µs ± 2% 7.95µs ± 2% +1.10% (p=0.023 n=10+10) MutexUncontended-2 8.10ns ± 0% 9.11ns ± 4% +12.44% (p=0.000 n=9+10) Mutex-2 32.9ns ± 9% 38.4ns ± 6% +16.58% (p=0.000 n=10+10) MutexSlack-2 93.4ns ± 1% 98.5ns ± 2% +5.39% (p=0.000 n=10+9) MutexWork-2 40.8ns ± 3% 43.8ns ± 7% +7.38% (p=0.000 n=10+9) MutexWorkSlack-2 98.6ns ± 5% 108.2ns ± 2% +9.80% (p=0.000 n=10+8) MutexNoSpin-2 399ns ± 1% 398ns ± 2% ~ (p=0.463 n=8+9) MutexSpin-2 1.99µs ± 3% 1.97µs ± 1% -0.81% (p=0.003 n=9+8) RWMutexWrite100-2 37.6ns ± 5% 46.0ns ± 4% +22.17% (p=0.000 n=10+8) RWMutexWrite10-2 50.1ns ± 6% 36.8ns ±12% -26.46% (p=0.000 n=9+10) RWMutexWorkWrite100-2 136ns ± 0% 134ns ± 2% -1.80% (p=0.001 n=7+9) RWMutexWorkWrite10-2 140ns ± 1% 138ns ± 1% -1.50% (p=0.000 n=10+10) Cond32 5.93µs ± 1% 5.91µs ± 0% ~ (p=0.411 n=9+10) MutexUncontended 15.9ns ± 0% 15.8ns ± 0% -0.63% (p=0.000 n=8+8) Mutex 15.9ns ± 0% 15.8ns ± 0% -0.44% (p=0.003 n=10+10) MutexSlack 26.9ns ± 3% 26.7ns ± 2% ~ (p=0.084 n=10+10) MutexWork 47.8ns ± 0% 47.9ns ± 0% +0.21% (p=0.014 n=9+8) MutexWorkSlack 54.9ns ± 3% 54.5ns ± 3% ~ (p=0.254 n=10+10) MutexNoSpin 786ns ± 2% 765ns ± 1% -2.66% (p=0.000 n=10+10) MutexSpin 3.87µs ± 1% 3.83µs ± 0% -0.85% (p=0.005 n=9+8) RWMutexWrite100 21.2ns ± 2% 21.0ns ± 1% -0.88% (p=0.018 n=10+9) RWMutexWrite10 22.6ns ± 1% 22.6ns ± 0% ~ (p=0.471 n=9+9) RWMutexWorkWrite100 132ns ± 0% 132ns ± 0% ~ (all samples are equal) RWMutexWorkWrite10 124ns ± 0% 123ns ± 0% ~ (p=0.656 n=10+10) Change-Id: I66412a3a0980df1233ad7a5a0cd9723b4274528b Reviewed-on: https://go-review.googlesource.com/34310 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org> |
|
Peter Weinberger
|
ca922b6d36 |
runtime: Profile goroutines holding contended mutexes.
runtime.SetMutexProfileFraction(n int) will capture 1/n-th of stack
traces of goroutines holding contended mutexes if n > 0. From runtime/pprof,
pprot.Lookup("mutex").WriteTo writes the accumulated
stack traces to w (in essentially the same format that blocking
profiling uses).
Change-Id: Ie0b54fa4226853d99aa42c14cb529ae586a8335a
Reviewed-on: https://go-review.googlesource.com/29650
Reviewed-by: Austin Clements <austin@google.com>
|
|
|
Russ Cox
|
40d81cf061 |
sync: throw, not panic, for unlock of unlocked mutex
The panic leaves the lock in an unusable state. Trying to panic with a usable state makes the lock significantly less efficient and scalable (see early CL patch sets and discussion). Instead, use runtime.throw, which will crash the program directly. In general throw is reserved for when the runtime detects truly serious, unrecoverable problems. This problem is certainly serious, and, without a significant performance hit, is unrecoverable. Fixes #13879. Change-Id: I41920d9e2317270c6f909957d195bd8b68177f8d Reviewed-on: https://go-review.googlesource.com/31359 Reviewed-by: Austin Clements <austin@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> |
|
|
Dmitry Vyukov
|
edcad8639a |
sync: add active spinning to Mutex
Currently sync.Mutex is fully cooperative. That is, once contention is discovered, the goroutine calls into scheduler. This is suboptimal as the resource can become free soon after (especially if critical sections are short). Server software usually runs at ~~50% CPU utilization, that is, switching to other goroutines is not necessary profitable. This change adds limited active spinning to sync.Mutex if: 1. running on a multicore machine and 2. GOMAXPROCS>1 and 3. there is at least one other running P and 4. local runq is empty. As opposed to runtime mutex we don't do passive spinning, because there can be work on global runq on on other Ps. benchmark old ns/op new ns/op delta BenchmarkMutexNoSpin 1271 1272 +0.08% BenchmarkMutexNoSpin-2 702 683 -2.71% BenchmarkMutexNoSpin-4 377 372 -1.33% BenchmarkMutexNoSpin-8 197 190 -3.55% BenchmarkMutexNoSpin-16 131 122 -6.87% BenchmarkMutexNoSpin-32 170 164 -3.53% BenchmarkMutexSpin 4724 4728 +0.08% BenchmarkMutexSpin-2 2501 2491 -0.40% BenchmarkMutexSpin-4 1330 1325 -0.38% BenchmarkMutexSpin-8 684 684 +0.00% BenchmarkMutexSpin-16 414 372 -10.14% BenchmarkMutexSpin-32 559 469 -16.10% BenchmarkMutex 19.1 19.1 +0.00% BenchmarkMutex-2 81.6 54.3 -33.46% BenchmarkMutex-4 143 100 -30.07% BenchmarkMutex-8 154 156 +1.30% BenchmarkMutex-16 140 159 +13.57% BenchmarkMutex-32 141 163 +15.60% BenchmarkMutexSlack 33.3 31.2 -6.31% BenchmarkMutexSlack-2 122 97.7 -19.92% BenchmarkMutexSlack-4 168 158 -5.95% BenchmarkMutexSlack-8 152 158 +3.95% BenchmarkMutexSlack-16 140 159 +13.57% BenchmarkMutexSlack-32 146 162 +10.96% BenchmarkMutexWork 154 154 +0.00% BenchmarkMutexWork-2 89.2 89.9 +0.78% BenchmarkMutexWork-4 139 86.1 -38.06% BenchmarkMutexWork-8 177 162 -8.47% BenchmarkMutexWork-16 170 173 +1.76% BenchmarkMutexWork-32 176 176 +0.00% BenchmarkMutexWorkSlack 160 160 +0.00% BenchmarkMutexWorkSlack-2 103 99.1 -3.79% BenchmarkMutexWorkSlack-4 155 148 -4.52% BenchmarkMutexWorkSlack-8 176 170 -3.41% BenchmarkMutexWorkSlack-16 170 173 +1.76% BenchmarkMutexWorkSlack-32 175 176 +0.57% "No work" benchmarks are not very interesting (BenchmarkMutex and BenchmarkMutexSlack), as they are absolutely not realistic. Fixes #8889 Change-Id: I6f14f42af1fa48f73a776fdd11f0af6dd2bb428b Reviewed-on: https://go-review.googlesource.com/5430 Reviewed-by: Rick Hudson <rlh@golang.org> Run-TryBot: Dmitry Vyukov <dvyukov@google.com> |
|
|
Russ Cox
|
c007ce824d |
build: move package sources from src/pkg to src
Preparation was in CL 134570043. This CL contains only the effect of 'hg mv src/pkg/* src'. For more about the move, see golang.org/s/go14nopkg. |