[Libre-soc-dev] load/store conditional

[Luke Kenneth Casson Leighton]

On Tuesday, May 25, 2021, Benjamin Herrenschmidt <benh at kernel.crashing.org>
wrote:

>
> > what appears to be missing is how many instructions are permitted
> > between a LR and an SC. without this information it imposes a
> > significantly higher hardware implementation cost and complexity than
> > might at first appear.
>
> There is no limit.


ok. this may have been discussed either internally or elsewhere: leaving an
indefinite RESERVE=1 to be arbitrarily matched up (or not at all) placing
the internal architecture under extra load, does not seem sensible.


> There is no concept of reservations expiring. I don't understand why
> your implementation would need such a thing.


caveat, here: we don't have an implementation, nor yet an understanding of
the details.


> Why ? The reservation is placed on the physical address after
> translation, you just need to hold onto that address and snoop for
> collisions.


context: this is an area that is (currently) outside of my experience,
consequently at the moment i am going from the playbook of the RV
architects, who made long deep studies of LR SC implementations.

RV's restrictions were designed to be extremely low cost and easy to
implement for lower-pergormance systems.

whilst i cannot (right now) answer your question directly, i would imagine
that these more experienced people in RV had analysed what happens when a
RESERVE is outstanding, and found that it has some adverse effect on the
TLB lookups (for instructions)

anything more, we have to wait, really, until it goes into microwatt, or
examine the A2I / A2O.

l.



-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68