Linus Torvalds (torvalds.delete@this.linux-foundation.org) on March 31, 2021 5:08 pm wrote:
> anon2 (anon.delete@this.anon.com) on March 31, 2021 3:46 pm wrote:
> > >
> > > For example, I see no sign that the ARM 'tstart' instruction has a success predictor
> > > behind it. And once again - without a hardware predictor, you can make up benchmarks
> > > that show how well it works, but real life will bite you in the arse.
> >
> > Wouldn't that be purely microarchitectural? What kind of sign would you expect to see
> > if they intended to implement such a thing (which I agree seems like a good idea).
>
> I agree that it could be seen as purely a microarchitectural detail, and not visible to users.
>
> However, even in that case, I'd expect there to be signs of it in the architecture definition.
> For example, the 'tstart' instruction should look a lot more like a branch, so that the predictor
> logic could act on it exactly that way, and just go to the fallback case.
>
> Another sign that ARM is not designing it with a transaction predictor in mind
> is that the result register doesn't have a "predicted not successful" case.
>
> That said, both could be added later: the first by simply just treating the 'tstart/cbnz'
> sequence as one fused instruction, and the second by adding a new error code. But since
> it's not there architecturally in the initial version, I'd expect that software then
> has to do the prediction for it, and then you're kind of stuck with that garbage.
>
> In fact, looking at the definition of 'tstart', I see all the same old
> signs that "yup, software is supposed to guess whether to try again".
>
> And there is zero question that you absolutely need prediction. Particularly with big transactions, you simply
> cannot afford to do a lot of work, only to then cause a failure just because of transaction size (and we know
> that some transactions will be fundamentally too large, if you try to use 'tstart' for locking).
>
> If the hardware doesn't do it, then the software has to do it, and that involves having software
> try to keep track of "this lock taker in this context has failed before due to transaction size
> issues, so let's not do the HW TM now because we know it's likely going to fail again".
>
> That kind of thing is expensive to do in software. You need to have counters for
> the the success/failure cases, and you need to somehow associate those counters
> with a particular code flow. Exactly like branch prediction hardware does.
>
> Honestly, anybody who tells me that software could do branch prediction is somebody who I
> wouldn't let near a new architecture. So why the h*ll do people think that software should
> do transaction success prediction? It's the exact same thing, with the exact same issues.
>
> Go look at the ARM papers, and tell me that there is any sign that they actually thought
> about this all. Because I don't see it. I see them barreling down the exact same mistakes
> that we've already seen with x86 and ppc, both of which have been abject failures.
>
> Anybody remember what the definition of insanity is, again?
>
> Linus

https://patents.google.com/patent/US10241933B2