RFC: AArch64: Implementing spin pauses with ISB

[Andrew Haley]

On 8/25/21 10:16 PM, Astigeevich, Evgeny wrote:

> IMHO, we've only scratched the surface of it. The problem is not
> well modelled by existing public benchmarks.  Yes, it is application
> dependent at some level.  In case of Thread.onSpinWait it depends on
> how an application implements spin loops.  Applications having spin
> loops with several iterations would benefit from short onSpinWait
> (this is what we've got in customers' benchmarks). Applications
> calling onSpinWait only couple times would benefit from longer
> onSpinWait.  "How heavy thread contention should be, what other
> places", these are still open questions. To answer them we need to
> detect the issues which is the problem itself.  What we currently
> use is the trial-and-error approach.

OK, thanks. I'm happy to approve a patch that switches NOP, PAUSE, and
ISB.

However, this all sounds a bit like cargo cult science to me. :-)

Some thoughts. In a high-contention case this is related to backoff in
transactional memory, where Dave Dice et al's TL2 (See "What really
makes transactions faster?" uses exponential*random backoff, like
Ethernet. The wisdom there is that you keep increasing the backoff
until it is about half the time that parking would take, then actually
park. That sounds intuitively reasonable.

But we don't need to do anything more if just adding an ISB is good
enough, at least for now. Let's do that, and see how it goes.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671