RFC: AArch64: Implementing spin pauses with ISB

[Stuart Monteith]

Hello,


On 17/08/2021 18:13, Astigeevich, Evgeny wrote:
> Hi Andrew,
> 
>> I guess that any instruction which caused a significant stall would reduce contention,
>> but it'd take some experiments to confirm that.
> 
> There are not many candidates for this: x-form of DIV up to 20 clocks, FSQRT up to 17 clocks. A sequence of them might work. ISB replaces such a sequence.
> ISB has a nice feature of flushing the pipeline which in theory means a delay without using ALU.
> 
>> Evgeny, did anyone try waiting on the monitor location with a WFE?
> 
> I am not aware of anyone tried WFE. IMHO WFE might be too complicated. It needs wakeup events.
> Armv8.7-A has WFE/WFI with timeouts. See https://static.linaro.org/connect/lvc20/presentations/LVC20-214-0.pdf  slide 10. They might be worth to try when WFET/WFIT appear in hardware.
> 
> Thanks,
> Evgeny
> 
> On 17/08/2021, 09:25, "hotspot-dev on behalf of Andrew Haley" <hotspot-dev-retn at openjdk.java.net on behalf of aph-open at littlepinkcloud.com> wrote:
> 
>      CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
> 
> 
> 
>      On 8/16/21 11:39 PM, Stuart Monteith wrote:
> 
>      >       This is interesting, and thank you for bringing it up for discussion here. The ISB instruction wasn't intended to be
>      > used for that purpose, so while you can measure a benefit for now, there is no guarantee that it would continue to be
>      > beneficial in the future. I hate to suggest adding more flags, but we ought to consider adding one to disable the ISB
>      > instruction in the spins. The counter argument is of course that we'd update the implementation as new cores come out.
> 
>      Indeed. It all sounds a bit like witchcraft to me. I guess that any instruction
>      which caused a significant stall would reduce contention, but it'd take some
>      experiments to confirm that.
> 
>      Evgeny, did anyone try waiting on the monitor location with a WFE? That'd at
>      least be using an instruction as intended, and would certainly reduce contention,
>      but WFE might be too drastic for a brief spin lock.
> 
>      --
>      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
> 
> 
> 
> 
> Amazon Development Centre (London) Ltd. Registered in England and Wales with registration number 04543232 with its registered office at 1 Principal Place, Worship Street, London EC2A 2FA, United Kingdom.
> 
> 

I don't think WFE will work for you - I found on at least one machine the cpu will pause more or less indefinitely. The 
SEV instruction may be a blunt weapon as it applies to all cores on the CPU.

This discussion appears split between the Spin Pause review and this email thread, but the idea of the implementation 
being switchable is appealing. Hypothetically the options might be NONE, NOP, ISB, YIELD. With the current semantics, 
YIELD could be theoretically useful on SMT cores, but I don't know if that would change in the future to be applicable 
more widely.


BR,
	Stuart