Investigate EH=1 usage more carefully

Our larx EH=1 lock hint can cause the processor hold the cache line exclusive for longer, until it detects a store to an address within the address modified by the larx/stcx.

Our "simple rwlock" read_lock implementation uses EH=1 which may actually not be the right thing to do for that lock because it will slow down other readers. It should be possible to make a simple test case (even in userspace) to verify that EH=0 would be better. The write_lock would probably still want to be EH=1.

EH=1 might be applicable in mutex_lock, where we don't currently use it today. It might also be applicable in rwsem_write_(try)lock. Finding some test cases and experimenting with EH=1 for those would be interesting.

Beyond that there may be other more obscure locks or important hand coded equivalents that could use EH=1, qrwlock, osq_lock, percpu rwsem, etc.

Tests should include a POWER10 because that has significant changes to the EH=1 behaviour.

No specific file or existing test is named. Start by tracing simple rwlock read_lock and write_lock, then inspect mutex_lock, rwsem_write_(try)lock, qrwlock, osq_lock, and percpu rwsem for EH=1 usage. Build userspace lock tests, include POWER10 runs, and use the results to determine where EH=1 improves or harms behavior.

Written by the indexing model from the issue text.