Replace Linux Mutex and Condvar with futex based ones.

[m-ou-se]

Tracking issue: #93740

[m-ou-se]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit 91395c3b1a30746e70384f354902866d8d8a6d8e with merge 21df0e4df7d5ac05ddfc314f462272f0da0cabb6...

[bors]

☀️ Try build successful - checks-actions
Build commit: 21df0e4df7d5ac05ddfc314f462272f0da0cabb6 (21df0e4df7d5ac05ddfc314f462272f0da0cabb6)

[bors]

☀️ Try build successful - checks-actions
Build commit: 21df0e4df7d5ac05ddfc314f462272f0da0cabb6 (21df0e4df7d5ac05ddfc314f462272f0da0cabb6)

[rust-timer]

Queued 21df0e4df7d5ac05ddfc314f462272f0da0cabb6 with parent 461e807, future comparison URL.

[rust-timer]

Finished benchmarking commit (21df0e4df7d5ac05ddfc314f462272f0da0cabb6): comparison url.

Summary: This benchmark run did not return any relevant results. 8 results were found to be statistically significant but too small to be relevant.

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led to changes in compiler perf.

@bors rollup=never
@rustbot label: +S-waiting-on-review -S-waiting-on-perf -perf-regression

[m-ou-se]

Realistic benchmarks are very hard, but here's some results using @matklad's https://github.com/matklad/lock-bench, using a 64C/128T AMD Threadripper:

The 'extreme contention' scenario (32 2 10000 100):

this new std::sync::Mutex        avg 27.645506ms  min 26.492286ms  max 28.900528ms 
current std::sync::Mutex (gnu)   avg 58.506588ms  min 45.996402ms  max 64.50891ms  
current std::sync::Mutex (musl)  avg 89.146548ms  min 85.399849ms  max 90.148675ms
parking_lot::Mutex               avg 313.074149ms min 302.646339ms max 319.321742ms
spin::Mutex                      avg 42.427277ms  min 39.371153ms  max 44.045329ms 
AmdSpinlock                      avg 44.313832ms  min 40.812916ms  max 46.40493ms  

The 'heavy contention' scenario (32 64 10000 100):

this new std::sync::Mutex       avg 1.822707ms   min 1.674482ms   max 2.081187ms
current std::sync::Mutex (gnu)  avg 8.10534ms    min 7.774234ms   max 9.279657ms  
current std::sync::Mutex (musl) avg 7.08335ms    min 6.889245ms   max 7.264291ms  
parking_lot::Mutex              avg 8.138322ms   min 2.282807ms   max 10.593921ms 
spin::Mutex                     avg 2.129469ms   min 2.024791ms   max 2.266706ms 
AmdSpinlock                     avg 2.026798ms   min 1.921888ms   max 2.154696ms  

The 'light contention' scenario (32 1000 10000 100):

this new std::sync::Mutex       avg 784.189µs    min 663.889µs    max 1.156756ms  
current std::sync::Mutex (gnu)  avg 2.802436ms   min 2.483913ms   max 3.781072ms  
current std::sync::Mutex (musl) avg 2.900143ms   min 2.795631ms   max 4.051815ms
parking_lot::Mutex              avg 695.039µs    min 573.318µs    max 921.173µs   
spin::Mutex                     avg 604.818µs    min 501.494µs    max 841.242µs   
AmdSpinlock                     avg 839.315µs    min 710.166µs    max 1.198424ms  

And finally, the 'no contention' scenario (32 1000000 10000 100):

this new std::sync::Mutex       avg 1.189231ms   min 807.39µs     max 1.50386ms
current std::sync::Mutex (gnu)  avg 2.97886ms    min 2.079744ms   max 3.96414ms   
current std::sync::Mutex (musl) avg 2.794938ms   min 2.732422ms   max 3.21436ms   
parking_lot::Mutex              avg 940.333µs    min 643.591µs    max 1.14756ms
spin::Mutex                     avg 765.141µs    min 565.754µs    max 983.661µs   
AmdSpinlock                     avg 856.35µs     min 615.248µs    max 1.07866ms   

[bors]

☔ The latest upstream changes (presumably #95173) made this pull request unmergeable. Please resolve the merge conflicts.

[jonhoo]

Is it worth marking this as relnotes?